[checkOutlinesUFO] Not every glyph has its overlaps removed

[robinsdg]

Running checkOutlinesUFO -e to produce a flat version (for production automation purposes) performs erratically. Using the -e flag does not always remove overlaps. I am struggling to find the reason why on a glyph or font level. Using the -w flag removes a few more overlaps than without, but it still leaves plenty of obvious cases (such as the attached /a/).

makeotf also seems to have problems with files having been through the -w process. The error src glyph aring is newer than processed layer. programName: CheckOutlines doesn’t mean anything to me, and I don’t understand why that’s a breaking issue.

[cjchapman]

Which version of checkOutlinesUFO are you using?

Also, would you be OK with sending me the font (or a subsetted version of it that exhibits the problem) for testing/debugging purposes? If you don't want to post it publicly, you can email me at my first initial followed by my last name at adobe dot com.

[benkiel]

src glyph aring is newer than processed layer. programName: CheckOutlines

Means that the outlines have changed since the last time checkOutlines was run (a hash is stored). makeOTF catches this and reports an error. If you run checkOutlines again, after you make the changes (nice to double check that all is fixed) then this error will go away

[miguelsousa]

@robinsdg in case you're not aware, checkOutlinesUFO does NOT change the outlines in the foreground layer. Instead, it creates a new layer (named glyphs.com.adobe.type.processedGlyphs) which will contain the outlines without overlaps. This layer will not contain all the glyphs in the font, only the ones that have overlaps (in the foreground layer).

Does this explain what you're experiencing?

[robinsdg]

This is the thing: the file this runs on is new. My shell script copies the UFO, runs the program on that file, and then deletes it again. In the older version (1.2.1 if I recall correctly), the file processed with the -e flag would compile through makeotf and use the processedGlyphs layer. This still seems to work in 2.0.0. But I recognise, @miguelsousa, that I should use the -w flag for this purpose. When I do that, I get the issue @benkiel mentions – which is weird because the program has run only once on that file. The UFO was made two seconds ago, basically.

[miguelsousa]

@robinsdg my guess is that there's a bug in the -w option.

[robinsdg]

@miguelsousa That’s what I believe as well. Would you like me to update the title to reflect this?

[miguelsousa]

It's not necessary right now. We can change it once we have a better idea of where the problem is. Thanks

[miguelsousa]

@robinsdg can you send us a one-glyph font that shows this problem.

[robinsdg]

I can’t manage to isolate this into a new font, sadly. I can privately send you a file that is giving me trouble, but it simply works so inconsistently that I can’t pare down the issue. Some glyphs flatten just fine in a build process with only the -e flag, which I still don’t know if the processedLayer gets used by makeOTF, some glyphs get skipped, and with the -w flag I get the ‘newer than processed layer’ error, meaning I just ended up with a build script that would run checkOutlinesUFO five times in a row, slowly working through the list. So, I can mail you and give you a new problem, or I hope it’s just a broken legacy file on my side and it won’t happen with new things.

[miguelsousa]

@robinsdg yes please send it to {name of the repository}at{name of the company}dotcom

[cjchapman]

@robinsdg (& @miguelsousa) I received the Project.zip file. Thanks.