Closed Bug 1427660 Opened 2 years ago Closed Last year
Hangul jamo in the range of U+A960–U+A97C do not form a syllable
70.61 KB, image/png
patch 1 - Make gfxTextRange::MatchType an enum class for stronger type checking (no functional change)
27.78 KB, patch
|Details | Diff | Splinter Review|
patch 2 - In gfxFontGroup::ComputeRanges, allow font run to include multiple match-types to avoid unnecessary interruption of font shaping
4.46 KB, patch
|Details | Diff | Splinter Review|
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.
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?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
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.
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.
Attachment #8974831 - Flags: review?(lsalzman)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
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.
Attachment #8974832 - Flags: review?(lsalzman)
Attachment #8974831 - Flags: review?(lsalzman) → review+
Attachment #8974832 - Flags: review?(lsalzman) → review+
Pushed by email@example.com: 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
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.
You need to log in before you can comment on or make changes to this bug.