`calt` feature no longer cycling through Cyrillic characters
arrowtype opened this issue · comments
As of a5d8e76, the calt feature stopped working to cycle through alternate Cyrillic glyphs. Before that point, this did work.
It does still work for Latin glyphs. I suspect it has something to do with production names getting applied unevenly (e.g. easy AFDKO names work for Latin glyphs, but not for Cyrillic).
Things that notably did not change in that commit:
- No real change to prep-build.py
- No change to build-vf.sh
Things that did change in that commit:
- I had just done a round-trip through Glyphs, to apply autokerning
- check if anything was added to the UFOs, like a list of production names, or a filter to "preserve glyph names" or something similar
- Just before, all glyphs (including alts) were getting renamed to "uniXXXX" style names. After, the alts kept their readable glyph names
- check the calt code at this point, and whether it seems to correctly indicate what to substitute
- It is possible that I had updated fontmake at that point (but I don’t currently know this), and that fontmake somehow changed how it handles uni-names and features
- investigate
- maaaaybe: I changed my vendor from
ARRWto@at this point- it seems unlikely but not impossible that this could result in various bugs. Easy test: change it back, build, and test
- it was suggested to me that a GPOS overflow, or group naming, might cause issues here
- test removing all kerning, then building – Nope, didn’t fix it
- test removing all kerning and groups, then building – Nope, didn’t fix it
Additional things to test
- use Simon’s ttf2fea script to inspect the features of a working vs not-working TTF. This might reveal a problem coming in from fontmake or elsewhere
- built with newer version of fontmake (3.4.0) — result: no change
- build with an older version of fontmake (3.0.0, 2.4.2) — result: no change
Possible solutions
- Account for production naming in calt fea code, rather than expecting fontmake to do so.
- If all else fails, I could change all names to uni-names in prep-build.py, and that should theoretically work.
It could be that the public.postscriptNames was added to the font libs ...
In earlier commits, this was empty. It’s hard to pinpoint exactly when this changed, or to say for sure that this specific change caused things to fail, but it seems related and possible.
shantell-sans/sources/shantell--extrabold.ufo/lib.plist
Lines 5733 to 5735 in 68a3b0f
Possibility: FontMake doesn't rename suffixed glyphs as well if a UFO has a postscriptNames dict in the lib.
- Test: empty the dict in prepped UFOs, then run the build again.
Emptying those dicts (using sources/02-scripts--shell/remove-lib-postscriptNames-in-dir.py) does result in a font with all glyphs named with uni-names. However, that alone didn't resolve the problem.
With an empty postscript dict:
I’ve tried decompiling features with otf2fea.
It seems like lookups are still targeting the correct glyph names, e.g. sub uni0414 by Decyr.alt2; is in the same lookup as sub A by A.alt2;. So, no obvious issues with glyph naming there.
Okay, possibly interesting: when I decompile font features using otf2fea, it gives this warning on fonts that are failing the calt cycle, but not on fonts that work:
# [warning] # XXX Unparsable rule: Mark to lig pos in 3
I’m not 100% sure what this might mean, but ... maybe it has something to do with the Ukrainian yukrcyr_yukrcyr (double ï)? No idea on this, but it seems like it might be interacting here.
Update: Simon Cozens said that in 3 is referring to lookup 3, though that so far doesn’t help me identify the problem.
- I’ll comment this out to see if it makes any difference. — result: still getting the error
- See if you can find what might be causing this error ... current guess: maybe something fontmake is generating for ccmp, mkmk features, or similar?
Make sure to add at least the following glyphs to the alts, which Anya considers to be a decent basic Cyrillic to cover the biggest Cyrillic languages:
So I think I would consider “Basic” Cyrillic as this:
АБВГҐДЕЁЄЖЗИЙІЇКЛМНОПРСТУЎФХЦЧШЩЪЫЬЭЮЯЂЅЈЉЊЋЏ абвгґдеёєжзийіїклмнопрстуўфхцчшщъыьэюяђѕјљњћџ
Okay, so... if I comment all feature code except for calt, it works again. Huh.
This happens in the full build, that doesn't currently work:
WARNING:fontTools.ttLib.tables.otBase:hb.repack failed to serialize 'GPOS', attempting fonttools resolutions ; the error message was: RepackerError
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 1, 'SubTableIndex:', None, 'ItemName:', None, 'ItemIndex:', None)
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 0, 'SubTableIndex:', 0, 'ItemName:', '<none>', 'ItemIndex:', None)
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 0, 'SubTableIndex:', 0, 'ItemName:', '<none>', 'ItemIndex:', None)
But it also happens when I comment out all features except for calt, which does work:
WARNING:fontTools.ttLib.tables.otBase:hb.repack failed to serialize 'GPOS', attempting fonttools resolutions ; the error message was: RepackerError
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 1, 'SubTableIndex:', None, 'ItemName:', None, 'ItemIndex:', None)
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 0, 'SubTableIndex:', 0, 'ItemName:', '<none>', 'ItemIndex:', None)
INFO:fontTools.ttLib.tables.otBase:Attempting to fix OTLOffsetOverflowError ('GPOS', 'LookupIndex:', 0, 'SubTableIndex:', 0, 'ItemName:', '<none>', 'ItemIndex:', None)