1427660 - Hangul jamo in the range of U+A960–U+A97C do not form a syllable

Status: RESOLVED FIXED

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

Description

[a]

Attachment: u115Eu1161-uA960u1161.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171226083017

Steps to reproduce:

OS: Windows 10 Home, version 1709, OS build 16299.125
Firefox version: 57.0.3 (64-bit)

data:text/html;charset=utf-8,%E1%85%9E%E1%85%A1%EA%A5%A0%E1%85%A1
(ᅞᅡꥠᅡ, U+115E U+1161 U+A960 U+1161)


Actual results:

Hangul jamo in the range of U+A960–U+A97C do not form a syllable.


Expected results:

Hangul jamo in the range of U+A960–U+A97C should form a syllable.

Comment 1

[Jonathan Kew [:jfkthame]]

WFM on macOS, provided the content uses a font that supports the characters involved (tried both Malgun Gothic and Source Han Serif). Do you still see a problem with current Nightly?

Comment 2

[Jonathan Kew [:jfkthame]]

Ah, interesting... testing further on Windows, I see that it works as expected *if* an appropriate font, such as Malgun Gothic, is explicitly applied in CSS, but fails if it is just using the default serif font -- even though that maps to Malgun Gothic so we'd expect to get the same result.

The reason is that the "basic" Hangul characters map to the Malgun Gothic font thanks to the Korean font-prefs setting; but A960 is not recognized as Korean by the font-matching code (maybe using nsUnicodeRange? I need to double-check...), so it reaches system fallback. The fallback still ends up finding Malgun Gothic, but it is treated as a separate font run because of the different font-selection code path.

Comment 3

[Jonathan Kew [:jfkthame]]

Yep, the most immediate cause of the problem here is that nsUnicodeRange doesn't know about this block. More generally, nsUnicodeRange is woefully out-of-date and not really fit for purpose (see also bug 723045).

Modifying text-run creation such that font runs found via prefs and those found via system fallback can merge would also resolve the problem.

Comment 4

[Jonathan Kew [:jfkthame]]

Attachment: patch 1 - Make gfxTextRange::MatchType an enum class for stronger type checking (no functional change)

This just changes the raw uint8_t used for these flags to a specific enum class, for better type-checking; there should be no change in behavior.

Comment 5

[Jonathan Kew [:jfkthame]]

Attachment: patch 2 - In gfxFontGroup::ComputeRanges, allow font run to include multiple match-types to avoid unnecessary interruption of font shaping

Here's the actual bug-fix: don't start a new font run just because the font was chosen via a different part of the font-matching algorithm. Instead, just record the additional match-type (for reporting via the InspectorFontFace API), but continue the same run so that shaping works properly.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c06d63503dfb
patch 1 - Make gfxTextRange::MatchType an enum class for stronger type checking (no functional change). r=lsalzman
https://hg.mozilla.org/integration/mozilla-inbound/rev/4670fe447a51
patch 2 - In gfxFontGroup::ComputeRanges, allow font run to include multiple match-types to avoid unnecessary interruption of font shaping. r=lsalzman

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/c06d63503dfb
https://hg.mozilla.org/mozilla-central/rev/4670fe447a51

Comment 8

[Ian Moody [:Kwan] (UTC+1)]

As a note, this also had the nice side-effect of fixing the three regional flag emojis, which had the same problem of not working unless you were explicit about `font-family: "Twemoji Mozilla"` in the site CSS.