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

Possible mismatch between ufos and glyphSets for preprocessor filters #583

Closed
yanone opened this issue Feb 4, 2022 · 2 comments
Closed

Comments

@yanone
Copy link

yanone commented Feb 4, 2022

I have a proprietary Glyphs VF here that I want to generate with fontmake, so for the time being I'm not linking a source.

It has three main masters. A few glyphs of the Regular master contain intermediate masters at {125} and {155}.

So in total, these are the masters:

  • Hairline
  • Regular
  • Regular {125}
  • Regular {155}
  • Black

It crashes because the flattenComponent filter can’t find a glyph in the glyphSet. I’ve traced the issue upwards in the call stack until here: https://github.com/googlefonts/ufo2ft/blob/main/Lib/ufo2ft/preProcessor.py#L282

There appears to be a mismatch between the ufo object and the glyphSet. glyphSet correctly contains only the glyphs that exist in that masters, which is all glyphs for the first Regular master, and significantly less for the two subsequent Regular masters representing the intermediate interpolations. However, the ufo object is identical for the three Regular masters. I could be wrong here, but this seems suspicious. Shouldn't there also be three separate ufo objects for the Regular out of the 5 total?

These are the total ufo objects as contained in self.ufos, and you can identify the middle 3 to be identical by its memory address:

[
<ufoLib2.objects.font.Font 'Oodle Sans Hairline' at 0x11168eaf0>,
<ufoLib2.objects.font.Font 'Oodle Sans Regular' at 0x11168e4c0>,
<ufoLib2.objects.font.Font 'Oodle Sans Regular' at 0x11168e4c0>,
<ufoLib2.objects.font.Font 'Oodle Sans Regular' at 0x11168e4c0>,
<ufoLib2.objects.font.Font 'Oodle Sans Black' at 0x119434a60>
]

And then, in the actual filter, an identical filtration is performed on all masters, but the second or third glyphSet of the Regular master doesn’t contain the required glyphs for that operation, so it throws a KeyError.

This is far as I could go, as I can't concentrate anymore at the moment. I can continue to dig but I need guidance. Anyone have an idea what's going on or where the ufo objects get assembled?

@yanone yanone changed the title Mismatch between ufos and glyphSets for preprocessor filters Possible mismatch between ufos and glyphSets for preprocessor filters Feb 4, 2022
@anthrotype
Copy link
Member

the master ufos are generated by glyphsLib. Brace layers get translated to additional layers within the same UFO as their linked master, in this case "Regular". So that is by design that you don't see 5 ufos, but only three, of which one contains two additional layers.
Now, masters can be "sparse" in the sense that any glyphs from the default master that are missing from non-default masters "do not participate" (i.e. produce no deltas).
But here's the catch: because of a limitation of UFO whereby component references can only occur within the same layer (see unified-font-object/ufo-spec#49), if you have a composite glyphs in a layer, the latter must also contain the base glyphs for those.
So as workaround for now, you should add the brace trick to all the base glyphs of the composite glyphs that have the brace trick, if that makes sense..
I think ufo2ft is working as intended, if you like this is more a bug report (feature request?) for glyphsLib. Though I am not sure whether/how this could be hanlded there..

@yanone
Copy link
Author

yanone commented Feb 5, 2022

Thank you. I got it to work by adding the intermediate layer to just one component glyph, so that was rather straight forward. Only to end up with other interpolation issues (as the decomposeTransformedComponents filter, too, is working on individual masters only).

I understand that a separate VF-first approach is needed. At least Simon has been speaking of this for a while now and I believe he has partial solutions cooking. So I'll close this for now.

@yanone yanone closed this as completed Feb 5, 2022
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