Inconsistent overshoots?

Jasper de Waard

Hi people,

I often find myself wanting to adjust overshoots depending on specific letters. For example, the S in a serifed typeface often needs less overshoot than the O, because the S is kind of flat-ish at both ends. I know the standard advice is to have one overshoot size for caps, one for lowercase, and then sometimes another for pointy characters like V. But I'm not sure if I want to follow that advice.

Is there any reason not to adjust the overshoot per letter? Am I being overly perfectionistic? How do you go about this? 

Best,
Jasper

Matthew Smith

I echo a lot of the responses in this twitter thread: https://twitter.com/ArrowType/status/1488648633704763392?s=20&t=qZBPJaJs0_QmgDV4aw_jyw

I tend to keep things consistent in the beginning for sake of speed and keeping track of everything, but then allow variation if needed.

Thomas Phinney

Absolutely, overshoot can be expected to vary between glyphs, when different shapes are involved. Flatter/wider elements need less overshoot, pointier/smaller bits need more.

The old terminology from PostScript is “blue zones.” They are indeed zones or bands, rather than a single height. Anything falling within the zone may be rounded to the non-overshoot height, at lower ppem sizes.

Christian Thalmann

Strange, I always have the urge to give /s/ slightly larger overshoots than /o/. Perhaps it's because I'm thinking of humanist sanses with relatively narrow (and thus pointy) /s/.

Jasper de Waard

Thanks for the advice, all! Glad to know I'm not the only one

On a related note, what happens to overshoots that fall outside the blue zones? For example in this n. I'd rather not stretch the blue zone to include the overshoot of the stem, because that would make it huge (adding 11 units to a 17 units blue zone), but is that gonna bite me in the ass later on?

Helmut Wollmersdorfer

Thomas Phinney said:

Absolutely, overshoot can be expected to vary between glyphs, when different shapes are involved. Flatter/wider elements need less overshoot, pointier/smaller bits need more.

Most modern fonts use some sort of overshoot up to 2% of total height. Whatever total high means. If I have the digital font available, I use the EM-size as total height. More reliable is maybe the hp-size (used in German typography). In optical recognition I try to cluster top and bottom, to get ascender, descender, baseline, x-line, capitals (H-line) and diacritic region.

Overshoot is just, what the designer feels it should be for visual recognition. Of course the good practise is very similar across designers, fonts and styles, but not a hard rule. Some fonts place all capitals exactly on the baseline.

Thomas Phinney

Your top-of-serif won’t get its overshoot controlled. That means it will not get rounded down to the x-height at any particular size, and may sometimes visible float above the x-height—especially at small sizes where the rounds are getting dropped to the x-height.

(All this is only in environments that pay attention to your hinting, meaning it won’t normally affect Mac or iOS.)

Whether this is a problem is in the eye of the beholder. At small sizes that sharp point is not going to be a full on pixel, just a gray bit. I note that Adobe Garamond Pro, which is similar in general design, does not put that top-of-serif in the blue zone, either. Minion Pro does not have the serif significantly higher than the arch of the “n” so it avoids the problem entirely.

Jasper de Waard

Thanks for your answer Thomas, that's what I was afraid of. I suppose I will have to do some testing, and the end-result might as well be that I widen the blue zone. Time to learn hinting!

Jasper de Waard

This is getting pretty technical so I apologize in advance. For TT hinting I came up with the following solution, and I'm curious what you think of it.

In the n, I can make the shoulder snap to the x-height, which works fine because it is in the 'blue zone', and then the stem also adjusts accordingly (or I can use a shift instruction). However, this solution does not work for letters like the i, because they do not have a point within the 'blue zone'. My solution (shown below), which seems to work fine, is to just add a point along the top serif of i that does fall in the 'blue zone', so that the rest can follow suit. Problem solved?

John Hudson

Why not just add a TT hinting CVT alignment zone for the actual top of the letter shape? TT hinting does not need to follow PS hinting, so you are not limited to ‘blue’ alignment zones. You can have two separate CVT alignments, have them collapse to the same height at smaller sizes, and choose the size at which you want to let the top of the the stem differ from that of the arch (or at which size you want to turn of gridfitting).

Jasper de Waard

Aha, that also works! Thanks

I'm not sure how to implement the separate alignments, though. Should I just make two overlapping alignment zones and handle the rest through hinting instructions, or is there a smarter way to create the alignment zones? Perhaps this is not possible in Glyphs app?

Edit: I think I found what you meant in Glyphs app.