I have an issue with UFOs. When I open an UFO file which I edited with MetricsMachine, Glyphs asks me to duplicate first (‘Duplicate’ and ‘OK’ buttons are available). Duplicating works and OK does not, and no matter whichever I click, the app asks the same thing again, and again, and again. The only solution is to duplicate the UFO and save it, force quit the app and delete the original UFO. I haven’t had a problem like this until the last version. Please investigate. Thanks!
It seems that Glyphs doesn’t recognise my custom XML anymore. It ignores decomposition rules, accent placement, legacy name, etc… Is there anything that the user should look into, or is it a bug?
Sometimes Glyphs does not show the master compatibility mark (little red triangle in the font view, red bar in the edit view), especially when it’s an imported font from both OTF and VFB. Again, is there something I should do or is it a bug?
Is there a way to tell Glyphs to add width of the accents to a composite glyph? e.g. Etatonos with the width of tonos, or Cyrillic Щ composed of Ш and a tooth with its width.
Thank you so much! I found the error in the XML and it’s working now.
I’m sure the “duplicate” dialogue didn’t behave like that in the past versions. If I clicked OK, it’d be gone and not appear until I attempted to modify the file again.
Okay, I have a further question with the XML. Most of the time I only need to add legacy names or composition rules, but do I simply need to add those, or do I need to complete a line?
This doesn't work in the way it should. I made Ш and a descender glyph (whose name starts with __) to make Щ and its width is the sum of two component widths, which is way wider on the right than it should be. I think the app should decide the glyph width by looking at the sidebearings of each component and the overlap.
That is what metric keys are for: Disable automatic alignment, set appropriate anchors, and the metric keys for LSB ("=Sha-cy") and RSB (e.g., "=toothComponent-cy").
Thanks. I was going to say that wouldn’t make sense, but it may be the consistent behaviour, although then I cannot imagine when __ naming would be handy.