search

pop-os / cosmic-text

Pure Rust multi-line text handling
https://pop-os.github.io/cosmic-text/cosmic_text/
Apache License 2.0
1.57k stars 100 forks source link

Urdu numerals display with Persian glyphs #214

Open ecton opened 7 months ago

ecton commented 7 months ago

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.

jackpot51 commented 7 months ago

We use locales to resolve han unification, this is probably the same kind of issue.

ecton commented 7 months ago

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.)

jackpot51 commented 7 months ago

Please see the han_unification function in src/font/fallback/unix.rs for an example of how that works.