I finally gave this a stab and coded a plugin for a functionality I felt would improve my work flow.
While the plugin is active any referenced glyph metrics will stay in sync with their linked keys. This means moving horizontal extreme nodes in a glyph that has metrics keys will maintain the linked side-bearing, but also editing a glyph’s side-bearing that other glyphs in turn reference will automatically keep those other glyphs’ metrics in sync in the background. Essentially I never wanted to have to use ctrl + cmd + alt + m ever again
The plugin is not added to the registry yet (pending this sanity check ), but you can check the code here and install for testing.
One question I have right away is about best practices. I used a reporter -type plugin for this, but it really doesn’t “Show” anything in the drawing area - is this an accepted hack, or should the plugin be using a different template instead to be more in tune with the semantics of the reporter plugin type?
Also, I’ve added a sort of internal caching for which glyphs need syncing, but I am not 100% certain this is implemented in the best way. Another issue I’ve not yet solved conceptually is how self referential linking (by mistake) should be handled, i.e. in the case that h links to n, but l links to h, and n gets updated; should only h get updated, or should the change propagate to any further metrics key links.
Feedback welcome, as are improvement suggestions (code or functionality).
The example template for the general plugin didn’t have the same method hooks for foreground etc., so I suppose that is why I went with the reporter initially. Are the same methods readily available in the general plugin, or do you have to use the more verbose addCallback method to add your hooks?
Cheers! Particularly how to store the checked / unchecked state of the menu item would have been impossible to figure out without the example. Is there a reason why your plugin doesn’t use Glyph’s own Glyphs.addCallback and uses some NS… function instead?
I noticed that the UPDATEINTERFACE listener doesn’t need to take any arguments, while the DRAWBACKGROUND needs to take the self, layer and info arguments; other than that my code is based on mekkablue’s.
Anyway, it work as a general plugin now, which feels like a better fit
As luck would have it I’ve also been working on a plugin to help with syncing metrics (although I took a v. different approach) here: https://github.com/jayKayEss/MetricsSolver
One thing that I noticed is that your regexp won’t catch a lot of glyph names… things like .sc etc. and scripts like Arabic. Feel free to steal the one I wrote here.
I really like how you’re trying to make this all transparent to the user (rather than adding an extra step, like I did) although I think the lack of recursion is going to trip a lot of people up (e.g. it’s sensible to set the RSB of Dcroat to =D, and the RSB of D to =O, in my opinion at least.) I also caught some dumb mistakes in my own font with the error checking in my plugin.
I wonder if there’s a way we could merge the two?
PS: I also found some extra metrics methods in the Obj-C libs (which don’t have much documentation) including a method to check if a glyph has unsync’d sidebearings… I wonder if we could get the Glyphs devs to update the Python libs to match?
Thanks for pointing me to your regex, I included it in an update to my plugin and submitted it for addition to the registry. Combining efforts would be great indeed, although I currently am too pressed for time to commit to anything. As a tool for my personal use I certainly would like to retain the transparent always-on approach of my implementation, other than that I am open to merge the two projects whichever way, some time in the future.
), but you can check the code here and install for testing.