Funny behaviour with RTL/LTR splitting in cursiveFeatureWriter

[cmyr]

Noticed this in NotoSansKannada, where we are generating a lookup with the RTL flag set, despite the fact that kannada is an LTR script.

The issue here is with various subscript glyphs, which do not have cmap entries. The logic for assigning glyphs to a writing direction requires a glyph to be explicitly LTR in order to end up in an LTR lookup, and any glyph that is not explicitly LTR is treated as RTL:

ufo2ft/Lib/ufo2ft/featureWriters/cursFeatureWriter.py

Line 76 in 98e8916

if glyphName not in dirGlyphs["LTR"]

I'm really not sure what a reasonable solution to this problem is, but I wanted to at least open an issue describing it.

[behdad]

@khaledhosny Can I get your opinion here? What should in your opinion cursive feature writer do? Looks like right not it defaults to the script direction.

[cmyr]

I'll add that I do think there is one reasonable heuristic that we could apply here.

The issue is that we are operating on a per-glyph basis, and the fallback path chooses RTL, which means that unmapped glyphs LTR glyphs can end up being assigned RTL (such as various subscript variants of glyphs, in this particular example.)

One solution for this particular problem is that if, after querying the per-glyph script direction, we end up with a single returned script direction (that is, we end up with some glyphs LTR or RTL, and the rest unknown) we should assume that all glyphs in the font should go in the same lookup, with the appropriate flag set/not set.

[anthrotype]

the LookupFlag RIGHT_TO_LEFT is about which glyph in a cursive attachment positioning sequence should rest on the baseline (first or last); that is usually related to the script direction but not necessarily the same thing. The cursFeatureWriter also supports cursive anchors that are suffixed with explicit .LTR or .RTL to avoid any guessing.

The issue here is with various subscript glyphs, which do not have cmap entries

could it be these aren't reachable via GSUB from glyphs that are mapped to unicodes associated with a LTR script direction?
The cursFeatureWriter is doing a GSUB closure and deciding to create two split lookups (without/with lookupflag RightToLeft) based on the presence of "LTR" among the closed-over "LTR" directly-cmapped glyphs.

ufo2ft/Lib/ufo2ft/featureWriters/cursFeatureWriter.py

Lines 40 to 48 in 98e8916

	def _makeCursiveFeature(self):
	cmap = self.makeUnicodeToGlyphNameMapping()
	if any(unicodeScriptDirection(uv) == "LTR" for uv in cmap):
	gsub = self.compileGSUB()
	extras = self.extraSubstitutions()
	dirGlyphs = classifyGlyphs(unicodeScriptDirection, cmap, gsub, extras)
	shouldSplit = "LTR" in dirGlyphs
	else:
	shouldSplit = False

I'm not sure if this fallback to RTL (for any glyphs not explicitly or indirectly marked as LTR) was intentional or not..

Maybe the solution is simply to do this:

- if glyphName not in dirGlyphs["LTR"]
+ if glyphName in dirGlyphs["RTL"]

... so that only those glyphs that end up (after the closure) in the "RTL" bucket are added to the RightToLeft lookup, whereas the neutral ones (neither LTR nor RTL) would simply be ignored/dropped (with a warning possibly)?

the cursFeatureWriter_test.py contains various tests for "mixed" situations with both LTR and RTL lookups, but as far as I can tell, all the RTL lookups only contain actual RTL glyphs.

should there be a intentional 'bias' towards RightToLeft in the cursive positioning such that, when in doubt, we should default to that?

[khaledhosny]

The defaulting to RTL was there when @moyogo wrote the initial version of that code. I kept it when I worked i that code assuming it was intentional (my thought was that cursive anchors are likely to be used in RTL scripts).

If these glyphs are unreachable, does it matter then? I guess we can default to not setting the RTL flag if it makes things simpler.

I’ll note again that, GlyphsData has script entries, and if we can make use of them, then we would not need the GSUB closure (at least for Glyphs files) and we can have a potential way for font author to fix such ambiguities by assigning a script to unreachable glyphs.

[khaledhosny]

One solution for this particular problem is that if, after querying the per-glyph script direction, we end up with a single returned script direction (that is, we end up with some glyphs LTR or RTL, and the rest unknown) we should assume that all glyphs in the font should go in the same lookup, with the appropriate flag set/not set.

Sounds reasonable.