Making a glyph compatible with different component structure

Glyphs
1

I have 2 masters, and an /n glyph,
Master A: 3 components,
Master B: 2 components & 1 path (because the component here needs to be specially adjusted – I don’t want to use smart components as it will complicate things and make format compatibility an issue.)

I tried using “Decompose Glyphs” parameter to try make it compatible but it doesn’t work.

It would be very useful to be able to make it compatible despite the different structure, I remember actually in the past it would still be compatible but only in the preview panel, and I wrote with Georg who mentioned in the preview panel it was decomposing the glyph before interpolating.

2

You will have to decompose the glyph or at least the third component, or create an alternate third component that works through all masters.

3

I specifically want to avoid this because this defeats the purpose of having a component, is there a way to set it to decompose before interpolating… without me manually doing this, I thought the custom parameter “Decompose Glyphs” would help but I don’t know if I got the order wrong or something?

4

Decompose kicks in before Rename, but is still after interpolation. We are thinking of adding an additional Pre-PreFilter for cases like this.

How often do you need this? And can you send us the font in question?

5

Sorry I can’t send the current font, but it has happened when the difference in weight between masters is quite large, so that where previously a component worked for multiply glyphs, suddenly doesn’t for every case because of optical correction in the boldest weight for example.

I’d say it happens usually in families with large weight changes between masters, and maybe 5–10 glyphs in Latin character set. Most recent case was, Italic ffi, ff, fl, etc ligatures glyphs in a serif typeface. Another case was sharing a component for the left stem in /r and /n, but no longer working in the black due to the tightness of the shoulder gap.

6

Another example is ogonek. In some masters, let’s say Regular and Bold, I can use the component “ogonekcomb” without alteration. On the other hand, the Thin master may require modification to keep ogonek smoothly connected to (for instance) stems of i and I. To make my glyphs compatible I have to either decompose ogoneks (very inconvenient) or create new version of ogonek (very inconvenient). I agree with oneweioranother’s idea, it would make my workflow better.

7

I actually do make separate ogoneks, is it really so inconvenient? I am asking because enabling something like this will lead to situations that are hard to debug. Tracking down a compatibility problem can be pretty tough, and things like correcting path direction or or fixing compatibility can become difficult.

8

It is quite inconvenient. But I just tried to create ogonek as smart component and it works pretty well. Unfortunately smart component imported as a component into ogonekcomb glyph does not keep its smartness so I have to build eogonek from e and _part.ogonek. But it works very well.