Okay, that title was a bit exaggerating. I know there are some (for me, extremely rare) cases in which the y value of anchors is relevant.
However, for me, as someone who designs mostly for Latin, I realized that having to deal with y values of anchors is an unnecessary hassle that does not give me any benefits. I use anchors primarily for automatic component positioning (and I know that they will end up in the exported fonts for the same purpose). In other words, all components in all glyphs in all masters are supposed to have zero y offset, except for very few exceptions. The main purpose of my Components Palette is to catch erroneously offset components, i.e. bugs in my font, caused by anchors not having the correct y value. For my current project, I ended up setting all top and _top anchors to the cap height, including lowercase and small caps. It would be most consequent to set all anchors in the whole font to y=0 but that would make editing more difficult because we have anchors on top of each other.
What I’d propose is that Glyphs supports “anchors without a y value”, maybe represented by something like a vertical line. As a result, all components positioned via “anchors without a y value” would have zero y offset. That would reduce data redundancy, reduce the potential for errors, and help users focus on the actual design questions (i.e. the x value of the anchors).
What’s more, I always set all x values of all anchors in all combining diacritics in all masters to the same x value, as the x value of these anchors is meaningless: The horizontal as well as vertical positioning is controlled by moving the shape. That’s another redundancy, it doesn’t give me any benefits, and another thing I need to keep consistent, and it can easily be messed up.
In other words, for almost all (Latin) diacritics, the positioning of the shape is currently controlled by six degrees of freedom (2 for each anchor, 2 via diacritic contour positioning) while in fact, we only need 3 degrees of freedom (2 for the shape position in the accented glyph, 1 letter-specific x value). It would be great if this could be reflected in the design and production process. For example, all combining diacritics could have implicit anchors, no anchors the user needs to see or even set manually. For the letters, all we need is a one-dimensional x-only anchor to control the horizontal positioning of the diacritic in that particular letter.
For Latin I would agree, and if there is still the option for y-pos kept, it might take away some pain (while adding some re-learning/unmusclememorying)
For other scripts and setups the y-pos is still more relevant, I think of Myanmar where we use flipped/mirrored shapes, nested and un-nested components/anchors etc, or Hangeul with smart components, where relative positions move along with shape length (height), just to name a few.
I guess this would lead to difficulty in selecting a specific anchor if multiple such a vertical-line-anchors lie on the same x coordinate, overlapping each other. Although this can be circumvented by placing the anchor name labels at slightly different heights, so you could click on the anchor name to select the anchor.
Thanks, I wasn’t aware that native speakers may place the accents in ľ and ť at different heights.
Still, the question is whether components with y offset are okay to use, or whether one would rather avoid them because it may mess up TT instructions. I personally try to completely avoid components with y offset (that also goes for things like small caps, of course).
And I know at least a bunch of designers that put top anchors higher above overshoots. Plus the ogonek anchors for U and e may be best above the baseline.
Tim, if you would like to automate the component placement without relaying on anchor’s y coordinate, here’s an idea.
When placing component:
Get x coordinate from anchor.
Get y coordinate from font vertical metrics (Baseline, Cap Height, etc) instead of anchors.
This way you will have components horizontally aligned to anchors and vertically aligned to font vertical metrics.
About an exceptions you mentioned, I guess it is about mark-to-mark placement or language-specific shifts. Here are some raw thoughts on how to get a specific font vertical metric (alignment zone) based on anchor name and glyph case:
bottom anchor = Baseline alignment zone.
top anchor in lowercase glyph = x-Height alignment zone.
top anchor in Small Caps glyph = Small Caps alignment zone (if specified).
top anchor in Small Caps glyph that already have top component (calculate manually) = Small Caps alignment zone (if specified) + height of existing top component(s).
top anchor in uppercase glyph = Cap Height alignment zone.
top anchor in uppercase glyph that already have top component (calculate manually) = Cap Height alignment zone + height of existing top component(s).
This will work as long as the user uses standard font metrics. And if not, here is a workaround for edge cases:
If some vertical metric / alignment zone doesn’t specified in font, you always can fallback to anchor’s y coordinate.
At the beginning of my original post, I mention that there are cases in which the y value of anchors is relevant. Now this thread has become mainly about those cases, which is completely missing the point. The current system of anchors works fine when we need a y offset. No deed to discuss these cases.
What I am interested in is those cases in which I do not want a y offset for the diacritic (for me >90%), and therefore having 6 degrees of freedom to effectively control 3 is not an ideal technique.
How should the anchors in the final font be set? Glyphs will need to write a y position for the anchors in the exported font. How do you want to control mark to mark positioning? (Honest question)
I suppose it wouldn’t be difficult to find a solution so that the behaviour of the font is as expected. Depends on the reasoning and inner working that are used when implementing the “anchors without y value”. In case there are only implicit automatic anchors in the combining diacritics glyphs then they would simply have these automatic positions in the exported font as well. In case one would really work only with y-less anchors then the y value of the exported anchors should not make any difference for the behaviour (effectively this is what I have been trying to explain here from the beginning).
Don’t worry, I get your reasoning. I also really dislike cleaning up clients’ files in terms of anchor positioning, especially when they decide to put anchors at very nonstandard heights (for example: _top anchor above the marks, so the top anchor then sits somewhere between x-height and ascender…). I just think this suggestion might overcomplicate things instead of simplifying them, despite there being a good reason for the idea in standard cases.
I have to admit that I don’t have much experience when it’s about anchors within the final font files. What exactly is the effect of your “cleaning up”? Does it change the behaviour of the font?
A solution I once saw is that anchors were all at y=0. For the design back then it worked and it was easy to check (three short lines of code) if the anchors were on the baseline.
Back then, I did recommend against it because it would make mkmk impossible, but which the design did not require anyway IIRC. It did make selecting difficult sometimes since different anchors would end up on top of each other.
AFAIK when an anchor is at coordinates 0, 0, its AnchorFormat record can be omitted from the GPOS table (markAnchorOffset is then NULL). But it would be trivial to normalize anchor positions on export, I think it’s nothing users should have to bother with, and I don’t have any idea how many bytes this could typically save.
