Some ligatures cannot be disabled, but are broken up anyway if they have spaces. |
||||||||
Issue descriptionWhile mucking about with SansBullshitSans I discovered that it does not appear to be possible to disable the ligatures. This font's only shaping is a 'liga' feature and applying font-variant-ligatures: none; font-feature-settings: "liga" 0, "dlig" 0; letter-spacing: 10px; does not disable the ligatures. I went so far as to make the change 'no_liga_test.diff' attached to force disable these ligatures, as well as output the feature settings. The local output is a lot of [1:1:1010/101520.725631:WARNING:harfbuzz_shaper.cc(769)] Features> [1:1:1010/101520.725750:WARNING:harfbuzz_shaper.cc(772)] Feature: liga value: 0 [1:1:1010/101520.725848:WARNING:harfbuzz_shaper.cc(772)] Feature: clig value: 0 [1:1:1010/101520.725944:WARNING:harfbuzz_shaper.cc(774)] <Features which shows that the code is trying to disable these, but something is causing the 'liga' feature to be applied anyway. This may be related to https://chromium.googlesource.com/chromium/src/+/7c6aeb96da8745b949f1a246a19e41f6d6772f4b/third_party/WebKit/LayoutTests/fast/text/font-ligature-letter-spacing-expected.txt having two FAIL expectations, but I cannot find a bug for that. Noticed on: 71.0.3565.0 (Developer Build) (64-bit) ab70ca4f282e87841287ffe1c8e8b44a2d04dff3-refs/heads/master@{#595120} Reproduced on: 69.0.3497.100 (Official Build) (64-bit) 8920e690dd011895672947112477d10d5c8afb09-refs/branch-heads/3497@{#948}
,
Oct 10
I will note that setting any of the css properties as in the original report does disable ligatures in 'Fira Sans'. I'm investigating if there is something interesting about the font itself, but is seems super odd to end up in a situation where ligatures get stuck 'on' (it seems much easier for them to be 'off', since they need to be applied).
,
Oct 10
Ok, so I think I know what is going on. SansBullshitSans sets requiredFeatureIndex to reference the feature tagged 'liga'. So HarfBuzz is always going to apply it pretty much no matter what (see required_feature_stage in hb_ot_map_builder_t::compile). I think this is what the designer of the font really wanted (though maybe 'rlig' would be better?). This leads to the unexpected behavior that the font designer really, really wanted these ligatures, but blink breaks them when they have spaces because blink is pretty sure it turned off ligatures so there shouldn't be any. However, it appears that between 'rlig' and requiredFeatureIndex it isn't entirely safe to assume that ligatures aren't going to happen.
,
Oct 10
It appears one can discover the required feature with hb_ot_layout_language_get_required_feature , so it is possible to know if a feature is going to be applied whether you wanted it or not. Somewhat related is https://github.com/harfbuzz/harfbuzz/issues/561 , as it would be nice to know not only if a glyph cluster is 'safe to break' but also if it 'should be broken' which may mean having some idea of which features went into making it.
,
Oct 11
Thanks for the analysis, sounds reasonable that we should sync the "can use word cache"-check, which checks for ligatures containing spaces, against the disabling / enabling of liga and the effect of required features.
,
Oct 12
,
Oct 13
HarfBuzz already provides all the info needed. Blink is falsely assuming that turning 'liga' off makes spaces safe to break. Otherwise, it has code to detect whether it's safe. And yes, that's a bad font design choice. 'rlig' sound right. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by bunge...@chromium.org
, Oct 10