Instance Custom Filter Transformation Offset Composite Component Bug

My apologies for the long title topic title.

I have instances with a custom parameter that shifts the font (for UI versions that have to fit into a certain rather limiting ascender and descender).

This works OK when I generate OTF’s. But TTFs retain composites. And when generating TTFs, then the offset, after being applied to the component glyphs, is also added to the offsets of components of composite glyphs. As the combined Glyphs-FontLab screenshot shows, that does not work well.

If it is any conciliation: it is not exactly the first case of font software adding shifts to component offsets…


  1. Set up a smart filter with only the glyphs containing paths
  2. Copy glyph names > comma-separated
  3. add ; include: after the parameter code, and paste the comma-separated glyph list behind it.
1 Like

This is an interesting work-around, but the issue is really caused by a bug that needs to be fixed at some stage.

I got the work-around to work, but it has its limitations. The first hurdle to take is to make sure that some composites, those with overlapping contours and are decomposed in the TTF, are also listed.
The real problem is of course that when I generate an OTF, the glyphs that were too high in the TTF will be loo low in the OTF. It might be easier, pending a fix, to use my own TTF tool to reset offsets if I have to ship TTF’s. (Which for the time being I don’t.)

I realized another problem with the work-around: there are anchor points. If you shift them all, or none, makes no difference. But now some are and others not.

The algorithm to shift a complete font is rather simple: composite offsets are left alone. Once you start to shift ranges of glyphs, for each composite element you will have to decide to leave the offset as it is, add the offset or subtract the offset.

The bug also affects the instance preview, with curious results…

Assuming both instances on right and left are the same one;
The interpolation should display only one glyph by weight order of each instance in the preview bar though;
So I do not understand how did you get that glyph on the right!

Could you send me the .glyphs file?

  1. Do not mix paths and components. Use parts for components, and connect with anchors. Otherwise such shifts out of sync are to be expected.
  2. What should happen if the user tries to shift a compound? Nothing? Seriously? I disagree because I do not think this is to be expected. What if the user specifically included only five compounds in the shifting process?

I am trying to get Glyphs to generate a shifted font variant. When a
complete font is shifted, all of the paths and anchors are shifted, and
all of the offsets must remain the same. Currently, when exporting a TTF
the shift is added to the offsets and therefore composite glyphs appear to
be shifted twice. Of course in a TTF a glyph is either an outline glyph or
a composite glyph. Glyphs that mix paths and components in source are
decomposed. When generating an OTF, everything is decomposed.
The preview of the instance is off course a separate case.

In theory when shifting a subset of glyphs:

For glyphs part of subset:

  • Outlines are shifted
  • Composite component with component glyph not in the subset: add shift to
  • Composite component with component glyph in the subset: no change to

For glyphs outside the subset:

  • Outlines stay where they are

  • Composite component with component glyph not in the subset: no change to

  • Composite component with component glyph in the subset: subtract shift
    from offset

I’ll mail the file for investigation.

I hope I have fixed it.