Anchor positioning habits

Adam Jagosz

What is your practice in positioning mark anchors? Do you set them on the baseline/x-height/cap height, or slightly below/above?

This will probably depend on the design, but generally, do you adjust the position to overshoots?

One thing is that placing the anchor over a node hinders its selection (in FontLab and FontForge, at least). Placing on height different than a guideline implies having to remember or check what the height should be (or adding a new guide...).

So I place the anchors on x-height/cap height/ascender height, baseline, and descender line mostly, and design the marks  as though positioned over an x-height letter or below a non-descending letter for bottom marks. If your approach is different, what are your reasons? I think I've seen fonts with the anchors mid-way between the letter and mark, are there any particular merits to such approach?

Lastly, does the chosen strategy affect the final result for different base and mark combinations?

Mark Simonson

I usually put anchors at the x-height/cap-height, but you're right, they could be anywhere that is convenient as long as you are aware of it.

I don't position them differently for overshoots normally. If overshoots are a problem, the accents are probably too close to the base character.

Robin Mientjes

I prefer setting top roughly halfway between x-height and cap, cap top at cap + 50, and bottom at baseline − 100. It just makes them easier to pick up, and makes them easy to spot – for example, to see if they’re roughly centred, before I start refining the positions.

Georg Seifert

I always recommend to put the anchos at the "edge" of the outline in the base glyph – meaning the x/cap-height. That way the distance between base and mark can be full controlled from the mark. And there is a guide already.
I see people put anchors above the metrics lines, presumably because in some font editors, there is a problem selecting an anchor if it is to closed to a node. But then you might like to switch to a different tool

This is much more important for Arabic or Indic typefaces where accents might be on different levels. And that becomes muddy when you start varying the height in the base glyph.

Thomas Phinney

I have mostly previously done what Georg recommends.

On my most recent project, I went with something offset 150/2000 from the x-height/cap-height/baseline, because that was the FontLab VI default, and it was just slightly easier not to change the vertical position of each anchor, after creating it.

The oddball height has not often been a problem or complication, but ... sometimes it is.  

In my next project, I shall definitely stick with staying right on the vertical metrics in the base glyph. Then the offset within the diacritic reflects the actual amount of distance between it and the base glyph ... all good.

Paul Hanslow

Thomas Phinney said:

I have mostly previously done what Georg recommends.

On my most recent project, I went with something offset 150/2000 from the x-height/cap-height/baseline, because that was the FontLab VI default, and it was just slightly easier not to change the vertical position of each anchor, after creating it.

I have found this to drive me bonkers when working on FLVI files imported to Glyphs. It's perfectly fine if anchors don't require repositioning in Glyphs, but it's a pain when they do. It's particularly annoying for italics when both the x and y coords of all anchors, in multiple weights have to be changed. This is even more complex when remembering multiple anchors heights for combining glyphs and non-Latins scripts. FLVI does has the advantage of displaying the coordinates of anchors on the anchor, while in Glyphs anchors need to be clicked to display their coords.

I wish software developers creating type design programs wouldn't be as naive to think that type designers only work in a single application, albeit theirs. This sometimes isn't the case and a broader approach should be taken to see what conventions exist, why they exist, and question if you're building on these conventions or just changing them cause you can.  **end rant**

Adam Jagosz said:

What is your practice in positioning mark anchors? Do you set them on the baseline/x-height/cap height, or slightly below/above?

Cap height for all cap anchors (with 'top.case')
x-height for all lowercase anchors (with 'top' )
small cap height for all small cap anchors if required (with 'top.sc')
Additional anchors are often required for specific cases (thee /Lcaron/ and /y with dot below/). Sometimes manually positioning a component is easier than using anchors.

Anchors become somewhat more complex when dealing with non-Latins. 

*edited due to grammatical error.

[Deleted User]

The user and all related content has been deleted.

Adam Jagosz

@James Montalbano I knew you were going to say this since I saw your other post when I was looking through threads on anchors. But here's this: anchors are not just for the designer's ease (or disease), they actually get exported and are used by some (albeit exotic) languages, for instance Marshallese, Yoruba, Akan, Lingala. These languages use characters that don't have precomposed glyphs, so they opt for using decomposed sequences instead, even for glyphs that exist in precomposed form. Sometimes texts contain a mixture of the approaches, i.e. precomposed accents with additional combining marks. Here's an example of a font without proper anchors in the accents (Alegreya Sans):

Arial for comparison:

I agree that designing Vietnamese might be quicker without anchors, though. Font design apps are also not very friendly toward edge cases like /L /I /i. FontForge works fine as long as you know what you're doing (you need separate lookups for exception anchors), while FontLab is a bit at loss (you need to do the same, but you can't assign anchors to lookups until you compile the code, so you're on your own).

[Deleted User]

The user and all related content has been deleted.

Adam Jagosz

You won't be contacted. I doubt they can afford paid fonts. And these who can, won't bother. But this issue affects a lot of fonts, including lots and endless lots of Google Fonts. Hence this is how Cyrillic transliteration looks like in Firefox (Chrome composes these on the fly, so Google doesn't know):

[Deleted User]

The user and all related content has been deleted.

Johannes Neumeier

James Montalbano said:

<<And these who can, won't bother.>>

So why should I?

Are the fonts you design products or tools?

[Deleted User]

The user and all related content has been deleted.

Johannes Neumeier

Your cynicism aside, I think what this boils down to is that particular distinction — and that is why I care. Are you selling something "as is" to whoever is willing to pay for it, or do you understand your craft as essential building block that enabled other creators.

Using combining accents and base glyphs that have attachment anchors you need not be concerned with diligently researching all glyphs using diacritics for the languages and uses you want to support (even though you should, for you own benefit ). You are simply supporting it beyond the possible limitations in you own knowledge or use cases you anticipate, and thus making your font a more useful tool for others to create with.

I also care because your attitude is something some type users associate with type designers, negatively so in my view, and I would like to understand what motivates your deliberate choice to not care.

To even attempt to bring this back to the original topic, I do strongly feel you should include all possible anchor attachments for all glyphs. For example GlyphsApp’s Glyph browser can tell you which anchors a base glyph can support according to their data (e.g. what combining glyphs and respective components’ anchor positions are needed), and even if you have no idea what some of those anchors should attach or in what language, it is still better to include them and make their positioning a deliberate design choice.

My practical implementation of this is a script that will create attachment anchors (if missing) based on a selected glyph’s path bounding box, with "left" and "right" anchors picking those extremes, "top" using center of cap height for uppercase or x-height lowercase, and "bottom" the center on the baseline. It is easy enough (as in quick) to just add those and do a quick review and tweaking of those anchor positions. If someone needs a /dcedilla/ or /gtilde/ or /aemacron/ I don't need to have those in my font and they will still work. In fact it would be a disservice to include all possible precomposites your font can accommodate, but even worse is to not support combining anchors at all.

Furthermore, when my fonts include caps versions of diacritics, I use the cap height for top anchors in the uppercase. When the design or brief does not call for specific cap versions of the combining anchors it is often better to place the top anchor in caps somewhat under the cap height, so that, in relation to the diacritic positioning on the lowercase (which I set anchors for on the x-height) the diacritics don't hover too far over the caps.

[Deleted User]

The user and all related content has been deleted.

[Deleted User]

The user and all related content has been deleted.

Adam Jagosz

Adam Jagosz said:

Font design apps are also not very friendly toward edge cases like /L /I /i. FontForge works fine as long as you know what you're doing (you need separate lookups for exception anchors), while FontLab is a bit at loss (you need to do the same, but you can't assign anchors to lookups until you compile the code, so you're on your own).

I think I was mistaken. After ordering the anchors in FontLab VI in both base and mark, so that the exception anchor is first in both glyphs, FontLab creates separate lookups in the 'mark' feature (with the exception anchor in the latter lookup). Awesome!

Georg Seifert

People do not complain because they don’t care but because the tech industry has conditioned us to not do it: https://pointersgonewild.com/2019/11/02/they-might-never-tell-you-its-broken/

Adam Jagosz

Exactly. That's what I meant by “won't bother”. They won't bother because it's our job to make things work, and if they don't, people will just move on and use the next best thing.

Christian Thalmann

Georg Seifert said:

I always recommend to put the anchos at the "edge" of the outline in the base glyph – meaning the x/cap-height.

I usually auto-generate the anchors with Glyphs and then manually slide them left or right, so they're on their respective guidelines by default...

...except for the ogonek anchor. It always seems to hover a bit above the baseline, so I hace to drag it down manually. Why is that?

(To be fair, though, I often draw vowel-ogonek glyphs with paths rather than components, since each vowel has different requirements for the attachment and sometimes needs to be adjusted itself.)

James Puckett

Christian Thalmann said:

...except for the ogonek anchor. It always seems to hover a bit above the baseline, so I hace to drag it down manually. Why is that?

I always thought it was to keep the ogonek and bottom anchors from being in the same place.

Adam Jagosz

I'd think this might rise from the assumption that uni0328 would be drawn totally below the baseline, so having the base anchor a bit above it would make for a desired small overlap between mark and base.

But I'm more used to positioning both anchors on baseline and drawing uni0328 a bit above the baseline instead. Then I unlink and adjust anyway, but I like the idea of having as little difference as possible between the precomposed, adjusted glyph, and the combining mark behavior.

Ray Larabie

Assuming the diacriticals are instances, is it possible for software to generate proper anchors from a font that doesn't have any? There are some "welded" ones like horns, ogoneks and sometimes cedillas but for the rest, isn't all the required offset info present in the font?

Kent Lew

I once started writing a script to do just that. Don’t recall now whether I ever finalized it.

Johannes Neumeier

Ray Larabie said:

Assuming the diacriticals are instances, is it possible for software to generate proper anchors from a font that doesn't have any? There are some "welded" ones like horns, ogoneks and sometimes cedillas but for the rest, isn't all the required offset info present in the font?

For the smooth transitions you’d need to at the very least follow certain conventions, but even then it is quite fickle. I have a macro for GlyphsApp that adds missing anchors (by comparison to possible anchors in the GlyphsApp database for that glyph) to selected glyphs, and while I can easily follow my own conventions for more standardized design of anchor positions, there is just no way to get it right how an /ogonek should fluidly attach to an /e’s terminal. I mean, it’s near impossible to give an exhaustive verbal description, let alone putting that into an algorithm. Most likely you’ll want some variation of the combining component specific to those cases, anyway

Still, this way I can just select all letters and automatically add somewhat okay anchor positions and then manually check which ones need tweaking — without having to think much about or know which anchors should be present in which glyphs.