Is it so hard to stick to the same anchor?

Hello, automatic alignment and anchors continue to be a pain in the behind. I constructed my P from components and later set more anchors in the base components to construct my Thorn and Softsign-cy. Upon re-opening the file, working a bit and saving, I checked the differences before committing my changes and saw that my P had changed:

Why does Glyphs decide to change to different anchors to use for alignment when I re-open a file? This is very dangerous and a real pain. Resolving this would be very much appreciated. Thanks!

After correcting the alignment and setting topright as my desired anchor, this line is added:

Before that, no anchor is defined and the component is aligned to whichever anchor was most recently added. Can that be?


Anchors are stored in a dictionary. And if there are several matching anchors it will pick one (e.g. the first). But saving them can change the order and that will change the alignment.

So you need to make sure you don’t have ambiguous anchors or manually set the anchor.

1 Like

I understand. Would it be possible to implement a warning when a file is newly opened and that new “random” anchors have been allocated? That would be fantastic, I don’t mind manually correcting them, I just would really need to know when such alignment changes happen.

1 Like

can you send me a sample font where that would happen. Maybe I can prevent it.

1 Like

I’ll try. Off the top of my head, the following should work:

  1. Create glyphs _bowl and _stem1
  2. Set anchors _topright and topright, respectively
  3. Build glyph glyph1 from the two components, enable automatic alignment
  4. Add anchors _center and center, respectively
  5. Build glyph glyph2 from the two components, select center as the desired connecting anchor
  6. Close and re-open the file

glyph1 now should have the components aligned like in glyph2, or at least, a new line containing anchor = topright should have been added to the .glyph file.

1 Like

I changed it that as soon as you add the center anchor, it stick to it. So you will see the change.

1 Like

And why do you use “topright/_topright” anchors instead of “#exit.topright/#entry.topright”. That way you can use the spacing of the “_stem” and “_bowl” in your “P”. (I just improved the support for multiple “#exit/#entry” anchors with suffixes.)

1 Like

Thanks, but I’m afraid that’s not going to be very useful. I don’t necessarily have the glyph1 open all the time.

Would it be possible to just add the change of alignment to the “Alignments changed” warning that pops up sometimes when a file has been edited in an older Glyphs version?

Glyphs detects that the alignment has changed when a file is opened again, the diff on the glyph1.glyph file shows changed alignments for the components. Is it not possible to display this as a warning? When Glyphs has to automatically pick an anchor and the components change alignment, that should definitely be a reason to warn.

1 Like

There are many reasons that the alignment will change on opening the file. If I would show the warning dialog, I would get a lot complains.
And with my change, the alignment should be updated on saving the file already. So you have to be careful if you allow ambiguity with several anchos.

I just tried another idea. Add “,” anchors to the _stem. And only one “#entry” in the _bowl. Because there is no direct match, it will not attach, only after you select an anchor manually.

1 Like

Alright. I still don’t understand, could there not be a warning for the following case:

A file is opened and Glyphs notices that there is anchor ambiguity (no connecting anchor selected for a component, and there are multiple anchors in the first component), so it chooses an anchor (a wrong anchor, perhaps). The alignment of the components might change.

1 Like

As I said. There are many reasons for not aligned components. And anticipating them is impossible for an algorithm (at least for an algorithm I can come up with).

Hello, I am trying to implement your suggestion of using #exit.bottomright, but the current 3231 build is missing your improved support for suffixed entry/exit anchors. Is this planned for a forthcoming update?

Offtopic, just because it’s interesting:

I just uploaded a new version.