You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This scenario has been coming up in FDK workshops periodically. I explain that VFs by themselves do not support extrapolation, but it is possible to “fake” an extrapolating VF, by extrapolating static UFOs, and assigning those as new sources.
The problem is that sometimes those new sources are no longer compatible – in this specific scenario, an implied closepath (contour 0 point 0) is extrapolated into non-existence:
Since the buildmasterotfs tool is basically just running makeotf, there is no reason for the tool to insert a closepath when start- and endpoint of the contour are equal (as in this example). The result is a set of incompatible OTFs.
When the buildcff2vf step is taken, this is the output:
Reading source fonts...
Building variable OTF (CFF2) font...
The input set requires compatibilization. Please try again with the -c (--check-compat) option.
using the -c option:
Reading source fonts...
Checking outline compatibility in source fonts...
Traceback (most recent call last):
File "/bin/buildcff2vf", line 8, in <module>
sys.exit(main())
File "/lib/python3.10/site-packages/afdko/buildcff2vf.py", line 564, in main
do_compatibility(vf, font_list, ds_data.base_idx)
File "/lib/python3.10/site-packages/afdko/buildcff2vf.py", line 332, in do_compatibility
region_charstring.draw(compat_pen)
File "/lib/python3.10/site-packages/fontTools/misc/psCharStrings.py", line 1148, in draw
extractor.execute(self)
File "/lib/python3.10/site-packages/fontTools/misc/psCharStrings.py", line 616, in execute
super().execute(charString)
File "/lib/python3.10/site-packages/fontTools/misc/psCharStrings.py", line 340, in execute
rv = handler(index)
File "/lib/python3.10/site-packages/fontTools/misc/psCharStrings.py", line 676, in op_rmoveto
self.rMoveTo(self.popallWidth())
File "/lib/python3.10/site-packages/fontTools/misc/psCharStrings.py", line 628, in rMoveTo
self.pen.moveTo(self._nextPoint(point))
File "/lib/python3.10/site-packages/fontTools/pens/basePen.py", line 324, in moveTo
self._moveTo(pt)
File "/lib/python3.10/site-packages/fontTools/varLib/cff.py", line 612, in _moveTo
self.add_point("rmoveto", pt_coords)
File "/lib/python3.10/site-packages/afdko/buildcff2vf.py", line 134, in add_point
raise VarLibCFFPointTypeMergeError(
fontTools.varLib.errors.VarLibCFFPointTypeMergeError: Glyph 'sterling': 'rmoveto' at point index 14 in master index 1 differs from the default font point type 'rlineto'
While this particular scenario may not be all too common, the fact that buildmasterotfs is unaware of point compatibility concerns is a problem.
The text was updated successfully, but these errors were encountered:
This happens because of generalizeCFF in buildmasterotfs. I'm not sure what the reason was for adding that, but maybe we should have a flag to skip it for situations like this. For CJK production I don't use buildmasterotfs because it's not needed at all. I just run makeotf.
This scenario has been coming up in FDK workshops periodically. I explain that VFs by themselves do not support extrapolation, but it is possible to “fake” an extrapolating VF, by extrapolating static UFOs, and assigning those as new sources.
The problem is that sometimes those new sources are no longer compatible – in this specific scenario, an implied closepath (contour 0 point 0) is extrapolated into non-existence:
Since the
buildmasterotfs
tool is basically just runningmakeotf
, there is no reason for the tool to insert a closepath when start- and endpoint of the contour are equal (as in this example). The result is a set of incompatible OTFs.When the
buildcff2vf
step is taken, this is the output:using the
-c
option:While this particular scenario may not be all too common, the fact that
buildmasterotfs
is unaware of point compatibility concerns is a problem.The text was updated successfully, but these errors were encountered: