In some cases, it’s super helpful that Glyphs considers differing components to be incompatible. For example, most often you would want to be warned that somehow a /breve-cy got put into your bold master where the others have /brevecomb (which might be rather hard to see).
But in other, admittedly rarer cases, differing components are intended. I have a pixel font that has some masters putting different pixel components in corresponding places. In this case the differing pixels are all point-compatible themselves. It would be handy here if compatibility indicators were triggered not by differing components, but only by differing components that are incompatible.
Not sure what a per-font setting interface would be to have that, but I thought I’d throw it out there as something I’d find useful.
Imagine a pixel font with say 3 x 8 components for a capital I
OOO
OOO
OOO
OOO
OOO
OOO
OOO
OOO
In the Regular master, all the pixels are the same little circle component. But maybe in the Gradation master, each horizontal row uses a successively lighter component from the one below. And in the Outline master, the 6 middle pixels surrounded by others are components with smaller paths.
Admittedly this is a very specialized situation. But more broadly it feels to me like interpolating between different but compatible components shouldn’t be a problem.
Ah, okay, so the pixels will not be calling for differing components, but for the same component at differing smart settings? I can work on a script to try out that conversion. (Will that change help with my crazy-long export times?)
Rainer’s suggestion might not work for your setup as it expects all pixels to be the same per glyph. And especially the “slightly heavier per row” cries for a smart component (as you don’t need a new component for each row).
About the crazy export time: do you have activated autohinting? (Don’t do that). If it is still slow, can you send me the file?
Can number value tokens be used to set Smart Component settings? (Putting them in the dialog doesn’t seem to be working; maybe by scripting?) Using per-master variables there would be a huge advantage for this.
Working on a script to swap out the differing component refs for the same component with different values.
When iterating through the old components, thus
Your code works for me. You need to make sure you use the right key. There is a property name and an Id. On a newly created smart glyph, the IDs are UUIDs (long random strings). When you save, close and re-open the file the property name and the axisId is set to the same value.