Originally reported as https://stackoverflow.com/questions/45416915/certain-ligatures-do-not-work-in-chrome .
The icon.ttf has a GSUB required feature 'liga' with two ligatures. The first ligature is <'page' 'monster'> => 'page monster' and the second is <'page' 'mathA'> => 'page mathA'. hb-view will apply both these ligatures; Chromium applies the <'page' 'monster'> but does not apply the <'page' 'math A'> ligature.
It appears that blink does not apply this second ligature because it is broken up by both the Symbols Iterator and Word Cache. Both 'page' and 'monster' are emoji so stay together, however 'page' is emoji and 'mathA' is text so the symbols iterator breaks them up. After disabling the symbols iterator the word breaker will also break them up, even with a zwj between them. As a result, to see this ligature in blink it is necessary to disable both. A super simple diff which allows things to work (and probably kills all perf) is attached to point out the relevant parts of the code.
Both of these seem fairly arbitrary, the symbol iterator seems to be more about picking the right font. In this case both 'runs' were satisfied by the same font without being re-merged, preventing the formation of the ligature. It is somewhat understandable that the word breaker broke these up, but even a zwj doesn't seem to prevent the word cache from breaking these two up. Perhaps instead of just 'does GSUB have a space in a rule' the criteria could be 'does GSUB have any rules which can be word-broken'?
|
Deleted:
index.html
869 bytes
|
|
Deleted:
icon.ttf
2.4 KB
|
|
Deleted:
disable_symbol_and_word_splitting.diff
1.4 KB
|
|
disable_symbol_and_word_splitting.diff
1.4 KB
Download
|
Comment 1 by e...@chromium.org
, Oct 12Status: Available (was: Untriaged)