googlefonts / googlefonts/fontmake
Error: "different number of segments" – EraseOpenCorners ufo2ft filter breaks compatibility in some glyphs
- Dominant language
- Python
- Stars
- 888
- Forks
- 97
- Avg merge
- 4d 52m
- Merged PRs (30d)
- 1
Description
This isn’t necessarily an issue in FontMake, and maybe it’s not an issue at all ... but it threw me for about an hour of debugging in a variable font build, so I wanted to record it here to point to a potential problem, and to perhaps help the next person who might stumble into this same obstacle.
I had a collection of sources that I knew were compatible to a high degree of certainty ... at least, I was checking them in every way I knew how to, after many previous variable font builds using FontMake. Turns out, I found another thing to check for in the future!
So, here was my problem: I was getting this error on a few glyphs within my designspace:
```
ERROR:cu2qu.ufo:Glyphs named 'Emcyr' have different number of segments
```
...and yet, I triple-checked that these glyphs had the same number of segments, the exact same start points, the same number of points, and the same types of segments.
I was stumped until I read through the FontMake output again, more closely. I spotted a line that was new to me:
> `INFO:ufo2ft.filters.base:Running EraseOpenCornersFilter on ShantellSans-ExtraBoldItalic`
Well, a primary change between this build and the last one is that I had run the sources through Glyphs, for kerning, then output back to UFOs, using ufo2glyphs then glyphs2ufo, respectively.
I know that handling open corners in builds has been a long goal in FontMake builds, and it looks like it’s finally happening! That’s great news overall, but I realize it must be very difficult to detect open corners with 100% accuracy, so some glyphs were tripping it up, in some of my sources.
To prevent this behavior, I had to add the following lib key to my source UFOs:
```
com.github.googlei18n.ufo2ft.filters
name
EraseOpenCorners
pre
0
```
(This is next to a couple of other important ufo2ft filter keys, `decomposeTransformedComponents` and `flattenComponents`, which are both set with `pre: 1`).
## My questions
(I’ll try to answer these, but I want to submit the issue first).
1. Was `EraseOpenCorners` recently added to FontMake or ufo2ft as a default step, or was this only activated by running things through GlyphsApp or GlyphsLib?
2. If this was triggered by going through GlyphsApp/GlyphsLib, where is that trigger stored in the UFO? I’m having a bit of trouble finding it when I search, but maybe I just need to keep looking.
3. Might there be any opportunity to improve the algorithm for the `EraseOpenCornersFilter`, or is it just a matter of it being impossible for a computer to do this 100% perfectly? I’m happy to share my repo privately if it would help, and it is intended for public, OFL release in a month or two.
Anyway, thanks for reading, and hopefully this helps save someone else some time!
Contributor guide
Assessment
This issue has not been assessed yet.