Can Glyphs generate mark-to-base code for custom anchors? I want to use top and bottom anchors on most of my base glyphs. But some base/mark combinations benefit from custom anchors, such as top.narrow. For example:
Here, the /dotaccentcomb is not using the top-anchor, but a custom top.narrow-anchor is present on the /b and on narrow marks:
The _top and _top.narrow are on the same position.
This works with precomposed glyphs (where I can choose the anchor I want with the anchor menu), but it does not generate the respective ‘mark’ feature code. I could write that code myself:
markClass [dotaccentcomb] <anchor 200 406> @mark_top_narrow;
markClass [dotaccentcomb.case] <anchor 200 604> @mark_top_narrow;
...
pos base b <anchor 236 604> mark @mark_top_narrow;
But that is cumbersome since the anchor coordinates need to updated manually, ignoring the additional complication of a multiple-master workflow where positions differ for each master.
I have been thinking about this issue some more and think that Glyphs can not automate the feature code generation, since Glyphs can not know in which order the custom anchors should be listed. (_top.narrow before or after _top.nested? Which has priority? Glyphs can’t know.)
So the mark/mkmk code needs to be written manually. Which is cumbersome because anchor coordinates need to be managed manually.
Maybe the token-concept could be extended to anchors? Similarly to how $pad is automatically replaced by a value from the master and $[case==smallCaps] is automatically replaced by a list of matching glyph names, there is now $<anchor glyph:label>.
So, instead of this code …
markClass [dotaccentcomb] <anchor 200 406> @mark_top_narrow;
markClass [dotaccentcomb.case] <anchor 200 604> @mark_top_narrow;
...
pos base b <anchor 236 604> mark @mark_top_narrow;
… one could write this code:
markClass [dotaccentcomb] $<anchor dotaccentcomb:_top> @mark_top_narrow;
markClass [dotaccentcomb.case] $<anchor dotaccentcomb.case:_top> @mark_top_narrow;
...
pos base b $<anchor b:top.narrow> mark @mark_top_narrow;
(or maybe even with glyph inference)
markClass [dotaccentcomb] $<anchor _top> @mark_top_narrow;
markClass [dotaccentcomb.case] $<anchor _top> @mark_top_narrow;
...
pos base b $<anchor top.narrow> mark @mark_top_narrow;
This would allow me to write the feature code myself with the anchor coordinates always up to date, automatically corrected for different masters, and even interpolatable between masters.
Also, I no longer need overlapping _top, _top.narrow, etc. anchors in my marks since compared to Glpyhs I know my own intensions and can just use the existing _top anchor for writing my top.narrow feature code.
I can fully understand that this (or any other new feature) is not the priority now with the recent release of Glyphs 3, Big Sur, and M1. Thank you for considering it!
FWIW, ufo2ft supports this and orders the lookups alphabetically (so making it at least predictable and one can change anchor names to get the desired order), it would be helpful if Glyphs support is compatible with it.
I just tried the new token syntax glyphname:property.keypath (as described in the change-log, section “New in Version 3.0.2 (3049)”) but I am getting the following error message and can not export my font:
I tried $[ ] and $( ) … but not ${ }. The token works now, all I had to do was change the top.narrow anchor name to top_narrow since the dot is now an operator.
. The token works now, all I had to do was change the 