Arabic question mark used with Adlam text falls back to a system font even when font contains the mark.

[NeilSureshPatel]

A review of various browsers on desktop and mobile show the Arabic question mark rendered from a system font fall back despite the Adlam font containing the appropriate glyph. This can be seen at the center of the last line in the attached screen grabs. This was briefly discussed during Meeting 7 W3C Font and Text Community Group. (Meeting notes in link) It is possibly related to a script itemization issue where Adlam is not properly recognized.

Chrome Mac OS:

Firefox Mac OS:

Edge Android:

Firefox Android:

Chrome Android:

Sample Inspection results from Firefox showing the question mark is rendered with Times New Roman.

[andjc]

I wonder if this is inherited from UCD, looking at Script Extensions, U+061F is associated with the following scripts: Arab, Rohg, Syrc, Thaa, Yezi. Have you tested in other African RTL scripts?

Although Arabic question mark fails in Yezidi text in Firefox, Works in Chrome and Edge, so I think there is a more fundamental issue with Firefox.

[NeilSureshPatel]

I have not tested other RTL African scripts. The two I can think of is Mende Kikakui, which I don't believe uses Arabic punctuation and Garay which has not been encoded yet.

[r12a]

N'Ko uses the Arabic question mark. Experimenting with my character app, it seems afaict that the glyph is rendered as expected when using Conakry, but there is no QM glyph in the Noto font.

[NeilSureshPatel]

Yes, I forgot about N'ko. I made a quick test on Windows since the default African system font is Ebrima which includes the QM. In these tests it looks like the incorrect font is used for the QM as well as the spaces. Spaces are rendered in the default body font while the QM is coming from a system font. This appears to be the case in Chrome as well. The glyph counts for each font matches Firefox.

Firefox:

Chrome:

[andjc]

Rendering engines more and more depend on UCD, so the absence of Adlam and N'ko for AQM in Script Extensions may be a factor.

[NeilSureshPatel]

Thanks. We discussed this a bit during the W3C Font and Text Community Group meeting and it was also confirmed that UCD Script Extensions plays a role in script itemization. I will move forward with getting the Script Extensions updated to include Adlam and N'ko to the appropriate Arabic punctuation marks.

[andjc]

Khaled in a recent tweet indicated that script itemisation was the responsibility of the client software, which should call the renderer indicating script and direction.

[NeilSureshPatel]

Another thing that Peter Constable brought up is that if a client has not been updated to even recognize a script that was recently encoded then it will by default treat the script as neutral. This can cause similar issues as well.

[r12a]

Does anyone have any news on this? I see thata request was made to the Unicode Consortium to fix the Script Extensions table, and that appears to have been done.

I'm not getting any better results, though. See https://github.com/w3c/character_phrase_tests/issues/54

[NeilSureshPatel]

Hmm no news on this issue. I did a bit of testing, and I am seeing the same thing. The Script Extensions Table has a publish date in December of 2022. Is it possible that implementation can take a long time?

[andjc]

Script extensions have been updated but that doesn't necessarily mean that user agents have been updated

[r12a]

Ok. I'll start raising browser bug reports then. Thanks.

[r12a]

Raised an issue for Gecko first, since @jfkthame may have insights into the required solution. If he does, i'll write more informed bug reports for Blink and WebKit.

There's a gap report at https://github.com/w3c/afrlreq/issues/19 to track this.