Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[buildmasterotfs] incompatible sources produced #1745

Open
frankrolf opened this issue May 28, 2024 · 2 comments
Open

[buildmasterotfs] incompatible sources produced #1745

frankrolf opened this issue May 28, 2024 · 2 comments

Comments

@frankrolf
Copy link
Member

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
Copy link
Member Author

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants