This applies mostly to fonts with composite glyphs and especially nested components:
Once I edit a base glyph, not all dependent composites update. When I save, the dot in the top-left window-close button either doesn’t disappear —signifying an unsaved state— or it does disappear, but upon cycling through masters and then saving it reappears, only to disappear and reappear once more after saving. I can confirm through Git diffs that indeed upon each saving more and more data is changed and saved. This continues almost ad infinitum. What makes matters worse is that this seems to apply only to glyph currently visible in the font view. Once I pull other glyphs into the font view, the game begins afresh.
I’m suspecting some form of updates of the composite glyphs happening upon saving. But only of visible glyphs. And only after I cycle through masters. This is easily the most unprofessional bug/feature of Glyphs, as I never know when data that I edited is actually saved or whether I’m actually losing data. For a font with several thousands of glyphs, it’s not possible for me to stay on top of this. I need this to work please. Glyphs need to be saved when I tell it to.
Besides, this has been going on for many years. One of the many things about Glyphs that I’ve just given up on. What is going on here and what can be done about it?
This is fixed in the 3.2 code.
But what happens here under the hood? Can you explain a little bit? I’m editing a 7-year long extensive font project and I’m legit scared that I’m losing data, at least for composite glyphs.
That the dot shows up all the time is caused by out of sync auto alignment. It was supposed to align everything just before saving the file but it didn’t do it properly. When you then scroll through font view, the alignment would kick in and dirty the document.
And how about aligning everything live when the data actually changes? When it happens on saving I still have the problem that the data isn’t up-to-date when I run QA tools on the live font in Glyphs such as generating proof PDFs.
I feel like everything should already be up to date when the file is saved.
Tjat shouldn’t be a problem as the alignment is updated as soon as you access the outlines (the bezierPath). if you use an api that isn’t triggering it, you need to call it yourself.
Do you have a sample where you can reproduce the output of unaligned components?
I have the same problem and it drives me absolutely mad. Half of my git commits are “update automatic alignment”. I currently just open a tab with all glyphs, and step through all masters (which can get very annoying with large numbers of masters). I would greatly appreciate at least the option of forcing an alignment update on all glyphs, preferably automatically on file save.
I don’t know how to reproduce it, because I don’t understand what’s happening. That’s why I’m so insecure.
I can reproduce one loop where I update a base glyph and it won’t adjust the composite glyphs right away, only after saving, and then I need to save a second time.
But the 10 or so loops that I need to go in order to successfully save after lots of work, I can’t reproduce that right now.
I understand that it’s to do with showing the glyphs in the font view. But I have close to 7000 glyphs and they don’t fit on the screen, not even two screens. And I need to cycle through all the 6 masters while showing all glyphs endless times before I can regard the file as saved.
All of this should be automatic, and not even upon saving, but right away when I edit. Yes, it needs to be a recursive update loop because components are commonly nested. I need all those glyphs to update right away.
I don’t even want to ask you if there’s a way to force the updates through the Python API, because Glyphs started with the promise to do all of that automatically and I really believe it should do that on its own.
And there was a time many years ago when all this used to work automatically, btw. It regressed.
@yanone I added you to the beta testing. Can you try the 3.2 version if it still has that problem?