Closed Bug 1716029 Opened 3 months ago Closed 3 months ago

Arabic ligatures not displaying correctly

Categories

(Core :: Layout: Text and Fonts, defect)

defect

Tracking

()

RESOLVED FIXED
91 Branch
Tracking Status
firefox91 --- fixed

People

(Reporter: mohd.akram, Assigned: jfkthame)

References

Details

Attachments

(7 files)

Attached file ligature.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 Edg/91.0.864.41

Steps to reproduce:

Open attached HTML file.

Actual results:

Number ligatures aren't formed correctly, digits are in the wrong order.

Expected results:

Number ligatures are displayed correctly. Numerals from 1 to 286 displayed as exactly 286 glyphs.

Attached file UthmanicHafs1.otf
Attached image safari-ligature.png
Attached image firefox-ligature.png

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → DOM: Core & HTML
Product: Firefox → Core

Does this alsp happen with any other font which does not limit the horizontal space for a number?

Or in different words: How does this weird font deal with a number which consists of fourteen digits? Does Safari still display that number correctly?

Flags: needinfo?(mohd.akram)
Attached image safari-14digits.png

The 14 digits ١٢٣٤٥٦٧٨٩٠١٢٣٤ (12345678901234) in Safari. It correctly groups the numbers by the longest possible ligature (in this font the largest number with a ligature is 286). Firefox seems to reverse the numbers, displaying them as (١)(٣٢)(٥٤)(٧٦)(٩٨)(٢١٠)(٤٣) which reads as 13254769821043.

Flags: needinfo?(mohd.akram)
Component: DOM: Core & HTML → Layout: Text and Fonts

This is related to directionality and how OpenType rules are applied, but I haven't examined it deeply enough to figure out whether the font is at fault, or harfbuzz, or firefox.... there are several levels of complication involved here, because of how digits appear in "reversed" order compared to the default ordering of Arabic script.

(Applying unicode-bidi: bidi-override to the content makes Firefox show the "expected" result, but whether that's correct behavior per spec or a workaround for broken behavior is not yet clear to me.)

FWIW, Chrome shows the same behavior as Firefox here -- unsurprisingly, as they both use harfbuzz to handle the font shaping. (That still doesn't confirm which behavior is more correct, though.)

The underlying issue here is https://github.com/harfbuzz/harfbuzz/issues/501. There may not be much we can do about it until a solution is devised within harfbuzz.

Severity: -- → S4
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: Firefox 90 → unspecified

As a workaround for now, I think we can special-case numeric runs in Arabic (or Hebrew) script contexts, and tell harfbuzz to shape with RTL directionality even though the run was resolved as LTR by bidi processing. This will allow the OpenType rules to work as expected for digits, as they will process the glyphs in logical order rather than considering them as "reversed" from the script's native direction.

With this, numbers in the UthmanicHafs1 font shape as expected.

Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bd9776af79de
Shape numeric runs in Arabic or Hebrew with RTL buffer directionality, so that OpenType rules will process glyphs in logical order. r=lsalzman
Flags: needinfo?(jfkthame)

OK, we need to be a bit more conservative about where this "hack" gets applied: if there are mirror-able characters (such as brackets) as part of the text being shaped, we mustn't flip the shaping directionality because this would unexpectedly switch their rendering.

In principle this could probably be done more narrowly within harfbuzz itself (potentially separating the directionality-for-OpenType-lookup-processing from the directionality-for-mirroring-purposes), but for now we can just check for mirrored chars and disable the tweak for such runs.

Flags: needinfo?(jfkthame)
Pushed by jkew@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8bcf47bf9ab1
Shape numeric runs in Arabic or Hebrew with RTL buffer directionality, so that OpenType rules will process glyphs in logical order. r=lsalzman
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
You need to log in before you can comment on or make changes to this bug.