Open ecton opened 7 months ago
We use locales to resolve han unification, this is probably the same kind of issue.
I've tried manually initializing the font system with the "ur_PK", and it doesn't change the behavior for me.
If this is done using locales, does this mean I need to keep separate Cosmic Text instances for each locale? Could an attribute be added to allow overriding the locale on a range or individual buffer? (Edit: It's been a while since I did this integration, holding a font system per locale seems reasonable.)
Please see the han_unification function in src/font/fallback/unix.rs for an example of how that works.
When rendering Urdu vs Persian numerals, it seems to be a font-glyph selection problem to determine whether to render Urdu characters vs Persian characters. I've been working on a crate to support numbered lists in various locales, and this edge case is the only one I've found like this.
I've installed Noto Nastaliq Urdu, and when I've manually set the font family to the exact family name from the
fontdb::Database
, the glyphs I see rendered are still the Persian glyphs:https://github.com/pop-os/cosmic-text/assets/50053/16640b7d-f906-4491-acd8-40e43ab1cc33
Because the exact same Unicode range is used for the different glyphs, I don't actually know how this should function under the hood. It feels like I should be informing Cosmic Text that the text is actually Urdu, but I don't know how. At a minimum, it feels like setting the font family explicitly should allow the correct glyphs to be used.
I'm not sure how to really help diagnose whether this is a problem with my setup or whether this should even be supported at the moment.