Cross-script kerning

[khaledhosny]

Since #679, kerning pairs are split per-script, under the assumption that OpenType layout is not applied across scripts.

As it turns out, there are more than one implementation that applies at least kerning across scripts (I have tested only Latin, Greek, Cyrillic, and Coptic, handling for other scripts might be different):

• CoreText applies kerning across the 4 tested scripts.
• InDesign’s Adobe Paragraph/Single-line Composer (see below)
• I’m told DirectWrite shapes Latin, Greek, and Cyrillic together, though I couldn’t manage to find a Windows application that shows this behavior.

There are also more than one orthography that uses a mix of scripts, so the issue here has potentially practical implications and not only theoretical ones:

• Sliammon language: uses Greek chi and theta mixed with Latin.
• Heiltsuk alphabet: uses Greek lambda and barred lambda mixed with Latin

Since the motivation for #679 was to optimize lookup sizes, and optimizations shouldn’t break functionality, I suggest to either:

• Revert this change and accept the sub-optimal lookup sizes
• Make the per-script behavior an opt-in
• Use a heuristic, e.g. if there are kerning pairs involving multiple scripts, keep these (or the kerning of involved scripts in general) in one lookup and register it for all the involved scripts.

Here are three fonts that include a couple of Latin, Greek, Cyrillic, and Coptic glyphs, with class kerning between them (all first glyphs in one class, and all second glyphs in another). The first font has the kerning lookup under DFLT script as well as script-specific tags, the second does not have it under DFLT, and the third has it under DFLT only: CrossScriptKerningFonts.zip

If kerning is applied, the text should appear solid with no space between the triangular shapes.

Here are the testing results for the string “AVАVΑVⲀVAУАУΑУⲀУAΥАΥΑΥⲀΥAⲨАⲨΑⲨⲀⲨ”:

• Pages: works the same for all three fonts
  
• InDesign (Adobe Paragraph Composer): seems to require the lookup under DFLT script
  
• Firefox (and basically every other application):
  

[behdad]

Let's file an HB issue as well...

[belluzj]

Kindof related (in the sense that having one big lookup would help with this Adobe quirk, which according to this issue is not so much of a quirk and more of a good thing?)

• Add LTR script kerning to DFLT for InDesign default composer #787
• Fix InDesign default composer kerning when mixing two scripts with a language selected #788

In the GPOS optimization code, instead of creating one lookup per script, we create one subtable "per script" (and don't change the lookup structure) (not really per script, but per matrix block spotted by the clustering code, but I guess it ends up being per script). That achieves the exact same behaviour as before the optimization, and it gets almost the same file size savings as splitting by script. The trade-off is that it doesn't speed up compilation, because we still start with building the gigantic all-scripts-together lookup, then we spend extra time analyzing it to split it into subtables.

Maybe the split-by-script code could try to split into subtables within the same lookup, instead of different lookups? The rules would be slightly different, as the subtables cannot apply to same glyph (first matching subtable wins), while several lookups can apply to the same glyph.

[anthrotype]

Use a heuristic, e.g. if there are kerning pairs involving multiple scripts, keep these (or the kerning of involved scripts in general) in one lookup and register it for all the involved scripts.

I'd be inclined to opt for this latter solution. Would you like to work on a PR?

[khaledhosny]

Use a heuristic, e.g. if there are kerning pairs involving multiple scripts, keep these (or the kerning of involved scripts in general) in one lookup and register it for all the involved scripts.

I'd be inclined to opt for this latter solution. Would you like to work on a PR?

Excellent. I’ll try to work on something in this direction.