Sync Metrics Keys - improvement suggestions for my first plugin?

Hey folks,

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 :smiley:

The plugin is not added to the registry yet (pending this sanity check :wink: ), 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).

I would have thought a general .glyphsPlugin is more fit for the purpose because you can add it to any menu, not just the View menu.

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?

Yes. Take a look into my SyncSelection plug-in.

1 Like

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?

When I wrote it, it didn’t work as expected. Not sure if it is fixed now.

The wrapper does some things automatically and it is good to know how to do it directly.

Agree. All good, just curious :wink:

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 :slight_smile:

1 Like

Hey Kontur!

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:

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?

1 Like

Sorry for the late reply :slight_smile:

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.