Wrong glyph digit shapes for extended arabic-indic digits
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: ishida, Unassigned)
References
Details
Attachments
(1 file)
71.56 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
This issue is applicable to Persian, Urdu and Sindhi.
Interactive test, The browser uses appropriate digit glyph shapes for Persian, Urdu, and Sindhi by default.
https://github.com/w3c/glyph_character_tests/issues/32
An intelligent opentype font may be able to detect the language of the text and substitute appropriate glyphs if it is used for the content, but here we are looking at the default behaviour of the browser, with no fonts explicitly assigned to the text.
Actual results:
Blink displays Persian digit glyphs in all three cases.
Webkit renders the correct glyphs for Persian and Urdu, but not for Sindhi.
Gecko renders Persian glyph shapes throughout, even though it uses different fonts for Persian vs. Urdu/Sindhi.
Expected results:
Persian, Urdu and Sindhi use extended-arabic-indic codepoints for digits in list counter styles. However, languages that use these code points tend to prefer specific glyph shapes for certain numbers, as shown here.
https://r12a.github.io/scripts/arab/ur.html#numbers
Reporter | ||
Comment 1•2 months ago
|
||
I suppose one fix for this would be to fall back to appropriate fonts based on the language of the text. There may also be other options i'm unaware of.
Comment 2•2 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 months ago
|
||
Firefox does pass the content language setting through to the font; whether this results in the "expected" digit shapes depends whether the font being used has support for localized numeral shapes. See the screenshot, where I have applied the Scheherazade font, and the digits take the expected forms for each language.
If the content is using a font that doesn't have this support, there's not much the browser can do about it; switching the digits to an entirely different font would often look worse.
Comment 4•2 months ago
|
||
The severity field is not set for this bug.
:boris, could you have a look please?
For more information, please visit BugBot documentation.
Comment 5•2 months ago
|
||
I think this is invalid as a Firefox bug; it's purely a question of whether the font provides the necessary features/glyphs. If the font supports the extended Arabic-Indic digit codepoints (U+06F0-06F9), we can't in general know which particular localized forms it's providing. We do pass through the language, so that full-featured fonts will work correctly.
Some results could be improved if we supported more language-specific font preferences, so that Arabic, Persian, Urdu and Sindhi could each specify their own generic fonts, instead of all being grouped together as "Arabic script". That's the sort of thing bug 556237 could enable. But that would only help when default/generic fonts are being used. There'd still be no guarantee of always seeing the correct forms, depending on the capabilities of available fonts and what the page actually specifies.
Description
•