googlefonts / googlefonts/fontmake

Error: "different number of segments" – EraseOpenCorners ufo2ft filter breaks compatibility in some glyphs

Open
#897 16 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.