freemix-glyphsapp
freemix-glyphsapp copied to clipboard
justanotherfoundry
Anchors palette order reshuffle after restart
Noticing an issue with anchor palette reshuffling the order of the anchors after restarting Glyphs.
For example:
I would reset the anchors which would order them
top
bottom
ogonek
when I save and restart, the order changes to
bottom
ogonek
top
Not sure if this is an issue with the plugin or Glyphs (3.0.5 (3112))
The anchors do not have a set order. So when you display a list of anchors, always sort them by name.
@gorjious Not sure I understand. Do you mean the Anchors palette changes the order of the anchors in the font (i.e. modifies the font), or are you talking about the order in which the anchors are displayed on the palette?
I think it is about the display, not the font. But the font may give them in different orders. They are sorted when saving to file.
So, as far as I understand:
- Gor was not satisfied with the display order in the Anchors palette.
- Then, without actively using the Anchors palette, he changed the order of the anchors, i.e. modifying the currently open font, with the (only) goal to improve the display order in the Anchors palette. This seemed to work.
- When saving the font file, Glyphs changed the order of the anchors in the font.
- When opening the font file again, the display order in the Anchors palette was not as desired.
Is this correct?
I think he just noticed that it is different after re-opening the file?
As Georg mentions there isn't a set order but there does seem to be a sequence in which Glyphs prefers to add anchors to a glyph..this can be seen in this screencast that only used Reset Anchors to set the placement of default anchors. Note how the sequence always starts with Top, Bottom then followed (typically) either by Ogonek or Center.
https://user-images.githubusercontent.com/23149420/153240653-d4ede24c-8fca-4441-8ae9-fd20780f689f.mov
In this screencast is the same file opened after saving and reopening. Note how the display order in Anchors Palette changes to alphabetical.
https://user-images.githubusercontent.com/23149420/153240787-bef87f47-0d5c-41ac-983b-8c167a40ec4e.mov
I find this bothersome for two reasons:
- the fact that the display order changes after re-opening the files
- the new sorted display order is alphabetical changes the visual reference
To expand on point 2, what I prefer about the original display (after reset anchors) is that the most common anchors shared across glyphs (top and bottom) are consistently displayed in the same sequence while additional anchors (center, ogonek, topleft, topright, etc) are added after which allows for me to have a visual reference of where to look to see if something is off (for example: if I'm going through to check positions of the top anchor, I have a sense that it will always be the first item in the list for all glyphs).
In this example below with the default anchors on O, what is helpful is being about to see the visual repetition of the 300 value for Top, Bottom, Center...if the x-position of any of those were off, it would be immediately apparent.
After Reset Anchors:
After re-opening:
What also disrupts the display order is re-inserting an anchor via copy-paste.
https://user-images.githubusercontent.com/23149420/153240941-95141dda-b241-433c-9a2f-65213fc6ab42.mov
💡That all being said perhaps an ideal system for the display order can be positional-based sorting which is agnostic of naming and can be based on the x-position from left to right with priority being of the y-position from top to bottom. The reason for the emphasis on the x-position is that it is typically the value being adjusted while the y-position is typically set on a metric line so if it is off then the visual diamond/round display of the anchor makes that apparent.
With positional-based sorting, the copy-paste issue wouldn't matter because the pasted anchor can re-inserted into the list based on its x-position. In the case that a user changes say the position of ogonek beyond topright, I wouldn't expect there to be some immediate resorting happening (which would be disruptive) however, in this case, it would make sense that these are re-sorted based on their new x-positions after saving and re-opening.
The order of generated anchors is completely random and never relevant. The change is not caused by this plugin but by glyphs saving them in alphabetical order to avoid noise in the file. So all the plugin could (or should) do is to always sort them when displaying them.
Ah okay, that makes sense. I guess the display order is more a matter of preference. The alphabetical sorting can still work but I'd be curious if the positional-based sorting would be more useful.
The sorting doesn’t need to be alphabetical. Just sort it to be consistent.
Currently, the list of anchors is sorted by the number of anchors in all selected glyphs: https://github.com/justanotherfoundry/freemix-glyphsapp/blob/109ca546db950047ed283b4eec025d88430ade9a/AnchorsPalette/Anchors.glyphsPalette/Contents/Resources/plugin.py#L94
I can change that to sorting by height, but what does that means? Average height (if multiple glyphs are selected)? Will play around and see whether this leads to a better behaviour.
@gorjious: It seems you want to compare the positions of anchors in different glyphs, and check whether they are consistent? In that case, I’d recommend to select multiple glyphs. If there is a number in the x or y field then that means the position of the anchor is identical in all glyphs. If it is empty then the position is not identical. If you find that a certain group of glyphs (let’s say, lowercase letters) doesn’t have consistent anchors (i.e. the y field is empty) then you can select the a and extend the selection one-by by pressing shift-right and as soon as the number disappears that means you have just selected the inconsistent glyph. Hope this makes sense.
Implemented in https://github.com/justanotherfoundry/freemix-glyphsapp/commit/934fddb0a901ea2c467746c43daeea9f247ae0fd Looks good?
Looks good. I think it makes sense sorting with the y-position.
I fiddled around a bit to also include the left to right x-position as the first pass of sorting then top to bottom y-position...essentially sorting all anchors from top-left to bottom-bottom.
Seeing it in this way makes sense for me but maybe just the y-position might be better for others.
The modification I tried was this:
if self.font.selectedLayers:
for layer in self.font.selectedLayers:
for anchor in layer.anchors:
if anchor.name not in anchorStats:
anchorStats[anchor.name] = [0, 0, 0]
anchorStats[anchor.name][0] += 1
anchorStats[anchor.name][1] += anchor.position.x
anchorStats[anchor.name][2] += anchor.position.y
# convert to a list, sorted by number of anchors:
anchorStats = sorted( anchorStats.items(), key=operator.itemgetter(1), reverse=True )
# trim to max MAX_NUMBER_OF_LINES elements:
del anchorStats[MAX_NUMBER_OF_LINES:]
# sort by average y position:
anchorStats = sorted( [(name, stat[1]/stat[0]) for name, stat in anchorStats], key=operator.itemgetter(1), reverse=False )
I recently started using Guides Palette and noticed that it allows for various sorting options using a custom parameter. Perhaps something similar could be added to Anchors Palette?
.
My apologies for reviving an old thread.
Implemented in 934fddb Looks good?
Sorting by y position is not a good idea in anchor-heavy script implementations such as Burmese, where it is a frequent occurrence that five anchors share the same y coordinate. Stepping through masters for a quick comparison of layers still yields different orders in every layer.
Why not sort by name? The names can assumed to be unique.
My apologies for reviving an old thread.
Implemented in 934fddb Looks good?
Sorting by y position is not a good idea in anchor-heavy script implementations such as Burmese, where it is a frequent occurrence that five anchors share the same y coordinate. Stepping through masters for a quick comparison of layers still yields different orders in every layer.
Why not sort by name? The names can assumed to be unique.
Yes! Thanks Rainer.
It’s hard to check if a glyph has the same anchors in different masters when the anchors don’t appear in the same order (they just show in the order they were added). As you see here many of the anchors are at y=0 but the order is muddled:
It would also be helpful to add a delete button something like this, so we don’t have to tab through all the anchors or try to click them when they’re often on the same coordinate as other anchors:
