-
Notifications
You must be signed in to change notification settings - Fork 52
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
Build intermediate layers with non-intermediate components #971
Conversation
just a terminology clarification: IIRC, an "alternate layer" in Glyphs.app has a specific meaning akin to so-called 'bracket' layers (that are swapped within given axis ranges) which is distinct from "intermediate layer" proper (aka 'brace' layers), best not to use the two interchangeably |
|
This deals with components which have intermediate layers being used in glyphs which don't (see #954), but that seems to work for me, so maybe the code is not needed.
148a990
to
60eb268
Compare
60eb268
to
8b758e6
Compare
@simoncozens is this ready to merge? or you plan to do more work to tackle #954 in here? |
IIUC this and the other #954 are basically two faces of the same problem, we want to make sure that composite glyphs and their components all have the same set of intermediate layers; in here, you fixed the issue when the composite has intermediates that the component has not; in #954, the component has more intermediate layers than the composite glyph that uses it, so we need to add the missing ones there. It's probably even possible (though unlikely) that the composite and the component have different intermediate layers for whatever reason, which means you need to add the respectively missing ones to both. |
let's merge this as is for now so I can make a new release |
I just tried this, and couldn't get it to work. But I'm not 100% sure this PR is solving the same problem. I have a font with 3-dimensional design space: weight, kashida, and swash. Layer setup per glyph as shown below. The composite glyph doesn't have any intermediate layers, which I thought this PR addresses. The width of the affected glyphs doesn't change along the kashida and swash axes, only the paths, hinting at missing intermediate layers in the composite glyph with adjusted width. |
no, this PR only addresses the issue when a composite glyph defines more intermediate layers than the component glyph that it references. You are hitting #954 -- glyph used as component has more intermediate layers than the composite glyph that uses it |
I had a feeling I got it mixed up. Thank you, I'll try out the other PR. |
there is not another PR yet.. |
I think I screwed up something here:
|
I presume this started happening since v6.6.2 (which includes this PR)? |
Yes, it's glyphs 3 source - I think we just didn't update an error message somewhere.
because I was trying to be clever and abstract out getting the location of an intermediate layer in a way that would kind of serve as documentation. But |
@simoncozens even after we merged #976, I'm still a bit puzzled by that glyphsLib/Lib/glyphsLib/classes.py Lines 3972 to 3982 in ce69aad
How can this
|
it was returning a generator expression for format_version>2 or a list for format_version=2 which doesn't make any sense #971 (comment)
I made it return a list so that comparison should work now (a944fd3) |
This is kind of the inverse of #954. If an
alternateintermediate layer references a component, and that component does not have a matching intermediate layer, glyphsLib currently generates a "too sparse" master. In the test file in this PR,Aslash
has an intermediate layer but it uses a component glyphA
which does not have that intermediate layer. Sometimes the resulting UFO file for the sparse master can't be compiled, because the referenced componentA
is missing; sometimes it can be compiled but there is no variation:There are two ways this could be addressed - we could interpolate and decompose the component, or we could make the sparse master a bit less sparse by interpolating the referenced layer. I've taken the second approach because (a) it's simpler, and (b) keeping components where possible can lead to smaller file sizes.
This also introduces a new way of preparing Glyphs files for Glyphs->UFO translation; we now have a
preflight_glyphs
function which runs a list of translations, progressively "dumbifying" all the smart stuff in theGSFont
object. Currently this is only used for the current job (de-sparsifying overly sparse masters), but in the future, we could use this to simplify some of the more gnarly translations we do in compilation, especially those requiring Glyphs-specific ufo2ft plugins. (i.e. EraseOpenCorners, CornerComponents, etc.)