search

adobe-type-tools / afdko

Adobe Font Development Kit for OpenType
https://adobe-type-tools.github.io/afdko/
Other
1.06k stars 167 forks source link

[buildmasterotfs] incompatible sources produced #1745

Open frankrolf opened 5 months ago

frankrolf commented 5 months ago

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: implied_closepath

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.

frankrolf commented 5 months ago

To reproduce the problem, you may use the attached source files and run the following commands:

makeinstancesufo -ac -d 1_extrapolation.designspace
buildmasterotfs -d 2_Exercise2.designspace
buildcff2vf -d 2_Exercise2.designspace

1745.zip

punchcutter commented 2 months ago

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.