[css-fonts] Clarify what ligatures are optional

[upsuper]

Recently we got a bug report that when text-justify: inter-character is specified, some characters which should be composed are instead separated.

I did some investigation and found that the reason is when that is specified, or a non-zero letter-spacing is specified, Gecko disables features liga and clig based on the CSS Text spec which states:

When the effective spacing between two characters is not zero (due to either justification or a non-zero value of letter-spacing), user agents should not apply optional ligatures.

while in this case, the composition is applied via clig feature. It sounds like clig is probably not an optional ligature.

But according to @jfkthame in the bug comment, the example in OpenType feature registry for clig clearly indicates it should be optional ligatures as it falls in the same category as ligatures like "fi". On the other hand, he also noticed that in shaping spec of some scripts, clig is also mentioned, which makes it less clear whether it is required, so maybe this should be conditionally treated optional.

It would probably be helpful if the spec can provide recommendation on what ligatures should be considered optional. Also any feedback from i18n wg would be great.

[svgeesus]

dlig should probably also be disabled (it is off by default, but could have been enabled) when letter-spacing is specified.

[r12a]

Ok, this is a bit like a ball of spaghetti. Let me try to unravel it a little.

First of all, the word បាទ used for the example is in the Khmer script, not Myanmar (see https://r12a.github.io/uniview/?charlist=%E1%9E%94%E1%9E%B6%E1%9E%91).

Second, the ligation occurs between a base character and a combining character, and my understanding is that they should not normally be separated by text-justify:inter-character, since they constitute a basic grapheme cluster. The units around which spacing occurs, according to https://drafts.csswg.org/css-text-3/#valdef-text-justify-inter-character, are what CSS calls 'typographic character units'. They are defined at https://drafts.csswg.org/css-text-3/#typographic-character-unit, which implies that a grapheme cluster is usually not broken (ie. you wouldn't want to separate បា).

However, third, in Thai (which is a different script again), the particular vowel-sign represented by the second character apparently is separated in certain similar circumstances, though not identical. This is actually described in an example in the spec (note that the example involves an additional combining character, the anusvara):

In other scripts such as Thai or Lao, even though for line-breaking the typographic character matches Unicode’s default grapheme clusters, for letter-spacing the relevant unit is less than a [UAX29] grapheme cluster, and may require decomposition or other substitutions before spacing can be inserted.

For instance, to properly letter-space the Thai word คำ (U+0E04 + U+0E33), the U+0E33 needs to be decomposed into U+0E4D + U+0E32, and then the extra letter-space inserted before the U+0E32: คํ า.

I'm not sure whether the presence of the anusvara (the small circle) is required to trigger this behaviour. That combination is also possible in Khmer (បាំ) and also has the special joining form of BA, but the example given is the simpler form.

So i guess there are a number of questions to ask here:

1. Is the reporter of the original bug concerned about Myanmar or Khmer text? Note that the equivalent in Myanmar, ပာဒ်, doesn't involve such a ligated form afaik, so i think they mean Khmer.

2. Does Khmer orthography expect U+1794 KHMER LETTER BA and U+17B6 KHMER VOWEL SIGN AA​ to be separated when text-justify:inter-character is applied?

3. Do the same rules apply for tracking as for justification? (The example of Thai above is actually in the context of letter-space, rather than justification iirc.)

4. If BA + AA are separated in Khmer, is the expectation that the special joining form of BA be retained or not? (I would assume not.)

We are in the process of putting together a group of experts in SE Asian scripts. I'll raise an issue asking them what the expected behaviour should be.

[r12a]

Oh, and btw, on Firefox 59.0.2 on Mac OS X 10.13.4 I don't see the separation reported anyway. I hope i'm not missing something...

[upsuper]

Right, this issue doesn't show up on macOS, probably because the font on macOS doesn't use clig for this ligature.

[nerdkid93]

@r12a I am the reporter of the original Firefox bug. I do not know all of the answers to your questions but I will do as best as I can.

1. I am concerned about Khmer. This appeared as an issue when we added l10n support for Khmer to one of our older web applications.
2. I would expect the letters BA + AA to not be separated since our translators told us that it looked like a "corrupted font" and the word was rendered unreadable (note: the following is a longer part of the original translated string from our application: វើ​ការ​វិនិច្ឆយ​បាន​ល្អ )
3. No idea
4. I don't think that BA + AA are supposed to be separated.

Let me know if I can answer any other questions about the issue and I'll do my best to get an answer for it!

[r12a]

Thanks for the clarification, @nerdkid93. I put up a couple of test files for Khmer and Thai at
https://w3c.github.io/i18n-tests/misc/justification/khmer_am.html
https://w3c.github.io/i18n-tests/misc/justification/thai_am.html

Interestingly, when i tried justifying on a Windows machine with Firefox, i didn't see any separation of the BA+AA glyphs for Khmer. (I did, however, for Thai, which i think is expected.)

[SergeyMalkin]

My few cents about why turning off ligatures automatically is not a good idea:

• Even for "simple scripts" this will be a problem. Switching off ligatures or contextual ligatures may change shaping results to look completely different. I don't want this to happen with even tiny spacing added.

• Situation is much worse when rule is applied to highly contextual complex scripts like Arabic. Section 8.2.1 of the spec even shows that Arabic requires special treatment where kashida should be used to increase inter-character space, and this will be

• My understanding of intent of turning off features is to prevent uneven spacing, when some glyphs are ligated and some not. But other shaping features can also be degraded sufficiently by spacing, for example cursive attachment or contextual shaping. Which means we don't actually know what features to disable. Ligature is obvious if font is "regular Latin font", but contextual alternates or stylistic sets will degrade significantly. Some stylistic sets are innocent and some are not, there is no way to know which ones.

• There may be threshold after which features can be turned on or off. IIRC, apps tried to apply heuristics to disable ligatures. InDesign turned them off when spacing was set to at least either 1/4em or 1/10em (I don't remember exactly). But this was very long time ago, when InDesign didn't support complex scripts or contextual alternates. They essentially knew what types of fonts they are dealing with, this is not true anymore.

• There are only few ways for how spacing can be introduced.

  • Inter-character justification, which is mostly applied to East Asian scripts. Ligatures or contextual shaping are rare between ideographs, so turning features on or off doesn't have much effect on shaping results anyway.
  • Arabic justification. This case doesn't require turning features off, it will insert kashidas or use justification alternates into already shaped text.
  • Another is explicit letter-spacing, but in this case I would expect web designer to know how much spacing is added, what font is used, what features are applied (and which ones are safer to use with spacing), and what scripts will be present. This means this is very likely that decision can be made based by designers and there is no much need for layout engine to make this decision for them.

• Finally, there are problems with how this rule is defined in the spec. First, I would expect rule to be not applied when spacing is applied to space character. Second, should ligatures be turned off only for two glyphs around additional space or whole text run? Should features be switched off for all text runs on the line, including ones using different font? How about inline blocks?

[fantasai]

@SergeyMalkin Explicit letter-spacing is an important case here, and no, actually, we cannot rely on the designer to know what's going on and definitely can't assume that a particular font will be used.

[SergeyMalkin]

I understand that it can't be guaranteed that particular font will be used. However, designers will know font with high enough confidence and if fallback still happens it is likely to be non-descript system font that will no break with or without features applied. For me, harm from automatically disabling features is much more than occasional rendering that is not ideal (given that spacing works correctly for complex scripts).