Repository navigation
Mark feature in Static fonts isn't able to be built as variable font #440
Description
Problem description
The feature code for the mark, mkmk, gdef feature for the static fonts causes fontmake to not be able to build the variable font. Error is VarLibMergeError: ((2, [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2]), 'int', '.LookupCount', 'Feature', '.Feature', 'FeatureRecord', '[0]', 'list', '.FeatureRecord', 'FeatureList', '.FeatureList', 'GPOS', '.table', 'table_G_P_O_S_').
Currently, the mark, mkmk, and gdef features are being built by fontmake for the var font.
Expected behavior
The same OT code can work for both fonts.
To Reproduce
Steps to reproduce the behavior:
To build_variable.py add:
from fontParts.fontshell import RFont as Font to the head of the file
Change line 7 to from utils import getFiles, make_mark_mkmk_gdef_feature
and then add these lines after line 21 (the end of the buildFeatures function)
for ufo in ufos:
font = Font(ufo)
mark_mkmk_gdef = make_mark_mkmk_gdef_feature(font)
font.features.text += mark_mkmk_gdef
font.save(font.path)
print("🏗 Added mark, mkmk, and GDEF to features")
Then run the variable fonts build.
Environment (please complete the following information):
Standard build environment.
Additional context
To pick this apart, the UFOs that are used for the variable fonts should be built with the static OT code (see above to reproduce). Those UFOs should be built with fontmake as TTFs, and then the GPOS tables compared to see where the difference is, along with an examination of the OT code for what might be triggering the issue. So far the OT code seems as though it should be making the same number of lookups in all fonts, but more investigation is needed.
Activity
arrowtype commentedon Mar 1, 2021
Thanks for taking the time to note these details, Ben!
Re-work feature writing code to use ufo2ft makrFeatureWriter instead …
benkiel commentedon Mar 3, 2021
Update on this. The issue seems to be with adding in the
markandbaseclasses to thegdeftable. If the code does not do that, the variable font builds just fine, with themarkandbasegdefclasses as built by fontmake/ufo2ft.I have changed the code to use the
ufo2ftmark feature builder for both the variable font and the static fonts however. That writer does generate warnings inmakeotfabout glyphs. (Example:Glyph 'Z' does not have an anchor point for a mark class that was used in a previous statement in the same lookup table. Setting the anchor point offset to 0.) I don't love that warning, but it does match what the variable font has for feature code. If later there are errors, one could go back to the feature code generator I wrote and use it.The variable font code does not write out the
gdefclasses, but does write the ligature carets. fontmake/ufo2ft will not write themarkandbaseclasses if there is a class defined (theligatureclass), so one can't write that one glyph class and have the rest fill in. This is the only difference now between the variable font and static fonts.Go back to custom mark feature code generation to better handle two t…