Broken Kannada shaping? #347
Comments
|
I’m sure this is a bug in HarfBuzz, see the discussions on notofonts/noto-fonts#341. |
|
I wrote GSUB rules for all Noto Serif Indic fonts, and I can confirm it's a HarfBuzz issue. HarfBuzz's handling of the "GDEF" table seems to be nonstandard, which leads to this issue. Noto Serif Kannada relies on A patched Noto Serif Kannada with a minimal change (setting the |
|
@KrasnayaPloshchad I don't think this issue is related to notofonts/noto-fonts#341 though. |
|
While patching SamsungOne fonts I've noticed HarfBuzz's exact issue seems to be: When a Unicode-mapped glyph's GDEF class is undefined in the GDEF table, HarfBuzz defaults its GDEF class to a value derived from UCD (eg, However, according to the OT spec, https://www.microsoft.com/typography/otspec/GDEF.htm —
— Which is indeed the common behavior of text engines (including earlier versions of HarfBuzz, eg, 0.9.40 and 1.0.5, according to Samsung's report). With the expected behavior of defaulting to 0, any glyph not assigned a class value in the GDEF table should not be ignored by Now the workaround for me is to patch the fonts by assigning non mark glyphs the class value of 1 "base glyph", like what happened (or was intended?) to have been done in Nirmala UI. |
|
@lianghai The GDEF behavior you mention is definitely not expected. HarfBuzz only fills in GDEF classes from Unicode data if there is no GDEF table present... Ugh. Now I see that this was changed in March, in: 69f9fbc |
|
@behdad Ah, I see… Though, given the clearly defined behavior of "any glyph not assigned a class value falls into Class zero (0)" in the OT spec, should the special case be actually Hebrew that does synthesize GDEF glyph class (instead of Indic-like shapers that do not)? |
|
@lianghai Yeah, I'm going to revert this, and make hebrew shaper ignore GDEF and GPOS (and use fallback for both) if GPOS Hebrew script system is not found. |
New approach to fix this: 69f9fbc Previous approach was reverted as it was too broad. See context: #347 (comment) With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable GDEF and GPOS, so we get results very close to Uniscribe, but slightly different since our fallback position logic is not exactly the same: Before: [gid1166=3+991|gid1142=0+737|gid5798=0+1434] After: [gid1166=3+991|gid1142=0@402,-26+0|gid5798=0+1434] Uniscribe: [gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]
|
Is this fixed now? |
…one in GDEF" This reverts commit 69f9fbc. See harfbuzz#347 (comment) Fixes harfbuzz#347
New approach to fix this: harfbuzz@69f9fbc Previous approach was reverted as it was too broad. See context: harfbuzz#347 (comment) With U+05E9,U+05B8,U+05C1,U+05DC and Arial Unicode, we now (correctly) disable GDEF and GPOS, so we get results very close to Uniscribe, but slightly different since our fallback position logic is not exactly the same: Before: [gid1166=3+991|gid1142=0+737|gid5798=0+1434] After: [gid1166=3+991|gid1142=0@402,-26+0|gid5798=0+1434] Uniscribe: [gid1166=3+991|gid1142=0@348,0+0|gid5798=0+1434]
|
Thank you for addressing this issue. I see that we have resolved this. But when will we see this updated in Chrome? when do they incorporate the updated harfbuzz? Could you please help me understand what version of harfbuzz is currently used in chrome. |
I don't know, but it should eventually make it to Chrome Stable. No further action is needed. @drott yet another nag to have HarfBuzz version visible in chrome://version or whereever... |
|
https://chromium.googlesource.com/chromium/src/ can be used to look at the HarfBuzz version that Chromium is compiled with. The first release version of HarfBuzz after e2b8780 is 1.4.0. In Chrome 57 we have rolled to HarfBuzz 1.4.1. @MayuraVerma you can try with Chrome Beta, which is at version 57. |
|
@drott Thank you. This is with the Chrome beta version. Finally NotoSerifKannada is rendering text correctly with updated harfbuzz.
Few questions: It could be off-topic, please bear with me.
Thanks. |
@MayuraVerma, do you know specific Unicode sequences that are broken? Feel free to add test cases to Unicode’s text rendering texts. Or simply file a bug with a list of strings that can be converted to test cases. Apple keeps an eye on the Unicode test suite, and they’ve fixed bugs in the past. |
|
@brawer sure, I will do that. |
Chrome on iOS uses Safari's WebKit as layout engine, this is not something we can currently change.
For changing default fonts in iOS Chrome (which would still go through CoreText), I would suggest to file a feature request on crbug.com. Otherwise, @brawer 's suggestion is probably your best bet for getting CoreText bugs fixed. |
|
is the limitation in iOS that doesn't allow browsers uses its know text engine? For changing default fonts: I will submit the cr right away. Besides Apple coretext issue for Kannada language, Apple system default font KannadasangamMN (TTF) has a lot bugs in it. Solving font issue with google fonts and reporting issues CoreText is right way to proceed for me. Apple is slowly changing TTF with new set of OTF for Indian languages. When they do that Coretext engine should not have issues. |
For NotoSerifKannada-Regular.ttf, HarfBuzz emits broken output while CoreText output looks good for the same font. This might be a bug in HarfBuzz. However, it might also be that CoreText has a bug in its Kannada shaping; I don’t know if Noto’s font designers have tested their font on multiple OpenType implementations or just on CoreText. So it might well be that the font (and CoreText) are buggy. If somebody who knows more about Kannada shaping could analyze this, it would be great.
I’ve added this as a test case to Unicode’s text rendering test suite, using CoreText to generate the expected renderings. Should it turn out that the HarfBuzz implementation is correct and CoreText (and the Noto font) are both wrong, I’ll of course adjust the test suite.
See https://github.com/googlei18n/noto-fonts/issues/759 for the corresponding bug report on the NotoSerifKannada font.
The text was updated successfully, but these errors were encountered: