I’ve recently run into an odd issue, I’m not sure if it’s a bug or the result of my design, but when I correct path direction in all masters a number of glyphs (without any obvious shared attributes/features) have their shape order changed to an incompatible order.
Below is a screen recording of me fixing the shape order of an ‘h’ then running the Correct Path Direction for All Masters command and opening the shape order panel again to find the order has been changed back to an incompatible state. What’s more confusing is that Glyphs doesn’t recognize this immediately but does notice the incompatibility after cycling through a few of the masters…
Has anyone run into this issue before? If so, is there a way to troubleshoot/solve the issue?
@GeorgSeifert That makes sense that path direction would change as a result of a changed shape order — but if the shape order is in a compatible arrangement, shouldn’t it be left unchanged when that (the shape order) helps determine path direction and not the other way around?
It’s probably more complicated than I understand, but logically it would make sense to leave the shape order unchanged if it’s compatible between all masters and try to adjust path directions to be in the same direction based on that shape order.
At the moment then, there’s no way to prevent this shape order change as part of correcting path direction?
Before running the command all of the shape orders and path directions seemed to be in the right shape order and paths running in the same direction — But I’m preparing to submit the font to the Monotype/Myfonts library and their font-validation/testing software returned an error indicating that I had conflicting path directions in Glyphs.
Even though everything was shown to be compatible, I ran the “Correct Path Directions in All Masters” on all the glyphs to make sure I didn’t miss anything. As a result, a few dozen glyphs had their shape order changed unintentionally.
As far as I can tell, when I go back in and correct things manually, all of the issues are resolved as long as I don’t try to correct path directions again. But I still wonder if it’s exporting conflicting path data that may be causing the failure on the Monotype font validator.
I understand this is out of Glyphs control though and that the Font Validator issue isn’t something you have insight on — I was just hoping there might be a solution by correcting all possible issues on the Glyphs side of the situation.
The automatic shape ordering still regularly messes things up for me. In this particular case, I cannot for the life of me understand how an algorithm can mix up the two /t/ stems… they have the same shape, and are far enough from each other so as not to overlap…
Might it not be the simplest solution to try out all possible permutations and pick the one that minimizes the overall length of the trajectories?
Hmm, you’ll still want to apply your old code to one of the masters to identify the proper orientation of each path. Maybe my suggestion would be best suited for a «Match path order to current master» function, allowing the user to pick the best-looking master as the reference.
There has to be some consideration to catch counters and order it behind the enclosing shapes. If you find an algorithm that works with a lot different shapes, I consider it.
Why should counters be behind?
Just had a chance to try it in a couple of fonts of 24 and 12 masters with italics, and here’s what failed in each case:
Note that this algorithm failed at ¤ rotating in italics, which of course confuses all x’s and y’s. Not bullet proof, but seems a bit more reliable in common scenarios.
for selectedLayer in Font.selectedLayers:
for layer in selectedLayer.parent.layers:
# sort by length, y, x
# round coordinates to 10, since smaller differences seem to be errors
layer.shapes = sorted( layer.shapes, key=lambda path: (len(shape), round(shape.bounds.origin.y, -1), round(shape.bounds.origin.x, -1) ))
