previously the glyphs have been compatable and i have made no changes.
the fix compatible filter shows all shapes lining up as they should
total node count matches.
theres no apparent way to make them more compatible than they are.
bug?
if i set up a new file from scratch with the same master setup and copy the glyph in question to the new file compatibility is positively indicated
Can you send me the file?
send as message attachment on the forum
Hey Rainer
did u have time to look into it?
i have several files that i would like to export that seem to suffer from this.
Can you send the files to support @ this domain? Then we both get them.
yes.
I just had a look, and it is the corner components. They need to be compatible now too.
yea i figured but in what way are they incompatible
what workflow exists to maintain them
Maybe this quick script in Macro Window helps:
# List Corner Components in Incompatible Glyphs:
for g in [g for g in Font.glyphs if len(g.layers[0].paths)>0 and not g.mastersCompatible]:
print
print g.name
for l in [l for l in g.layers if l.layerId == l.associatedMasterId]:
print ", ".join( [h.name for h in l.hints] ), "---", l.name
yea frankly this is not particularly helpful.
also i have a script that matches the corners across masters
which does seem to fix it,
that is the incompatible indicator disappears after i run the script and move the paths left and right (so it recognizes change)
but if i open export dialog its back to incompatible again.
very very frustrating
even if i delete all corners from all masters exept one and then manually paste them to the others theres no success
could it be that there are multiple corners asigned to the same node?
i believe that is currently possible (shouldnt be)
That can happen.
it shouldnt 
rainer is there a way to remove dublicate corners with a macro?
i am asuming that they are configured identically…
Take a peek inside my Propagate Corners script. You should be able to find all the code snippets you need there. Or perhaps the script suffices for your needs? It takes the corner structure of the current layer and recreates it throughout all other layers.
I have been using the script yes. very useful,
actually i wrote something similar a while ago with the help of a friend ,
since some of the django is beyond my current abilities.
regarding your script:
i asume it checks on each layer in whatever asymetric way u may have corners on any layer and distributes them to all other layers that currently do not have them. What if there are multiple corners on one tho? shouldnt it clean that up too…
So since you have such script maybe it makes most sense that you maintain/extend it for this edgecase.
I suspect other people use this script too and have the same issue i experience.
Don’t mean to sound like i am making demands here,
i understand your time is limited too…
another thing i noticed while skipped through the corners pressing tab is that the corners seem to have a arbitrary order, that is not matching the nodes itself. it seems its based on order of creation. i cant say that seems very logical too me.
shouldnt it rather switch clockwise to the next connected to a node on the path?
one more thing.
this whole thing with corners being incompatible,
seems mainly based on the corner meta data, not on the corner paths.
the paths in my example are compatible and therefor should be interpolatable, regardless of not having the matching names.
im not certain in which cases u would want to purposefully use different corners like this.
just pointing out another edgecase
The compatibility is always only about the data inside that glyph. An Adieresis can be compatible, even if the A or the dieresis are not.