Why ascender can't use interline gap, but diacritics can?

Igor Petrovic · October 14

It is a norm that the basic Latin characters don't go beyond the em space.

And now I have a kind of typical situation in Black master. Lowercase /f and /i need more space (on the ascender side) for the hook and dot. I lowered the /f bar and /i apex a bit, but I still need more space.

Why is it a good idea not to go beyond the defined ascender here, if diacritic characters will do it anyway? Or I can go over the ascender a bit, anyway?

John Hudson · October 14

You can definitely do this. The relationship of outlines to the body (em) height is arbitrary but conventional. So if you have an existing design with a particular relationship to the body height, and then add another master or some additional glyphs that need to be taller, then they can extend beyond the em height. You just need to be aware of the impact on apparent linespacing.

John Savard · October 14

I can see one reason why, despite the way TrueType and OpenType actually work, as John Hudson had explained, that the convention that ascenders must stay within the bounding box, while diacritics are more free had arisen.

Texts will always include letters with ascenders.

Diacritics, though, are... optional.

At least if your language happens to be English.

So, since, in my personal opinion, it's kind of silly to have a font which can't be set solid at whatever its nominal point size is, the conclusion is that if it's a font serving other Latin alphabet languages then those diacritics ought to be pulled strictly within the bounding box too - thus going outside the convention in the other direction.

Of course, allowing diacritics on upper-case characters to go outside the box is still a legitimate option, since whether or not to use them is considered to be a choice in many languages that use accents.

In the era of hot metal, of course, accented capital letters that fit within the nominal line spacing by being shrunk below their accents were a thing. That tends not to be bothered with nowadays.

Igor Petrovic · October 15

Thanks for your answers, they are very helpful. Now I realize that I understood vertical metrics correctly in the technical sense, but not so much in the theoretical sense.

I was focused on why the em square can't be crossed. While the real point is that if it needs to be crossed, then the whole font should be somewhat smaller, because it is the relative value. Except if you are trying to have letters as big as they can be at a given text size, which is not my goal.

That said, it is a relief to know that — at least for now — I can just overreach the defined ascender, instead of adjusting all the other glyphs in both masters.

Thanks.

Thomas Phinney · October 15

John Savard said:

I can see one reason why, despite the way TrueType and OpenType actually work, as John Hudson had explained, that the convention that ascenders must stay within the bounding box, while diacritics are more free had arisen.
Texts will always include letters with ascenders.
Diacritics, though, are... optional.
At least if your language happens to be English.
So, since, in my personal opinion, it's kind of silly to have a font which can't be set solid at whatever its nominal point size is, the conclusion is...

I disagree on kind of all counts.

It is NOT a convention “ that ascenders must stay within the bounding box, while diacritics are more free”

That statement doesn’t resemble at all what John Hudson wrote, above.

“Diacritics, though, are... optional.

At least if your language happens to be English.”

Why on earth would we make fonts with diacritics, but ignore the needs of the people who use them?
These days, western European coverage is the bare minimum. Including some version of CE accents is pretty normal. Even Vietnamese coverage is no longer rare.

John Savard · October 16

Thomas Phinney said:

It is NOT a convention “ that ascenders must stay within the bounding box, while diacritics are more free”

That statement doesn’t resemble at all what John Hudson wrote, above.

It wasn't intended to. It was a reference to what the original poster had stated. I was in no way disputing that John Hudson was correct in saying that ascenders are just as free to go outside the bounding box as diacritics in a technical sense; but just because you can, in fact, do it with OpenType and so on doesn't make it impossible that there is a popular view that you shouldn't do it for ascenders, while doing it for diacritics is OK. Maybe the OP was wrong, and this popular view doesn't exist. I didn't claim to know either way, but I did feel that such a popular view could exist - it sounded plausible, and I gave the reasons why it seemed plausible to me.

John Hudson · October 17

Much depends on where in the development cycle of a family of fonts one discovers that maybe one needs a little more space within the body height for the extenders of a particular weight and style.

Ideally, this is something you work out early, with a small set of trial glyphs including one ascender and one descender, that you create at least roughly for all the planned weights and styles. But sometimes you find yourself adding new weights and styles, either later in the design development or, indeed, after the first release of the typeface. If fonts have already been released, rescaling the whole design is effectively not an option, since compatibility with existing versions and avoiding impact on existing document layouts are paramount concerns. But even if you have not released fonts, making general scaling adjustments is something I would avoid because rounding errors will introduce a lot of inconsistencies.

So while it is generally the case that one wants extenders to fit within the body height—this is what one would typically aim to do in a thoroughly planned family—, there are conditions in which allowing them to extend beyond it in some weights and styles is the sensible decision.

Jacob Casal · October 17

Relevant to the discussion, as I similarly wondered about vertical metrics in regards to non-swashed Latin characters without diacritics: it has been very helpful in grasping this conceptually by examining via editor how other fonts I have on hand have handled said extenders.

Here are a couple of small examples: When looking at Harriet I noticed its overshoots go just a touch above the ascender line value and out of the em box, Rameau does similarly but with its descender overshoots. A couple other fonts I have do similarly to these two, sometimes both overshooting a little bit above and below the em box.

A bigger example: I had been wondering why HTF Didot appears so much larger at its nominal point size relative to similar fonts with close to the same proportions of x-height, ascender, and descender values. Looking closer, I found that its actual descenders dip significantly below the value of its descender line and leave the em box. At the same time the actual ascenders did not reach all the way up to its ascender line value. These elements allowed it to have a larger x-height than if everything was confined to its em box and thus it renders larger than similarly proportioned fonts when typed (if I am understanding it correctly).

The above being said, the utilization of the Line Gap value, whether or not the OS/2.UseTypoMetrics flag is checked, and the general coordination of the vertical metrics need to be accounted for too when looking at these fonts. I’ll also mention here that the above examples were all in their Regular weight (and HTF Didot in its Medium weight, consistently observed across optical sizes).

As for swashed Latin fonts, John Hudson mentioned in a different TypeDrawers post about looking at Gabriola and Zapfino; looking at those two fonts helped me become more comfortable with idea that, if sensibly needed and coordinated, type elements can significantly leave the em box and still be okay.

Peter Constable · October 18

While it doesn't directly answer the question, a way I think it's useful to think about the vertical font metrics is:

The size of outlines in relation to the em height will affect how the size of a font compares to other fonts.
A variation on the above: the size of a glyph outline will affect how its size compares to that of other glyphs in the font.
The vertical metrics will affect default line spacing in many apps (and most apps don't provide author control over line spacing).

One of my long-time rants has been how these have affected some Thai fonts, such as the UPC fonts that were introduced in Windows 3.1 timeframe: Thai text uses vertical space differently than Latin text and generally requires larger line height. But in the Thai edition of Windows 3.1, the sizing of UI controls was set and Thai UI strings needed to fit legibly. That made it necessary to design the Thai glyphs smaller in relation to the em height than would otherwise have been desirable in a font. As a result, Thai text looks too small compared to other fonts.

There were 9 Thai families in Windows 3.1. Only one of which was used for UI text, but they were all designed with the same approach to metrics. Ignoring the UI requirements, it would have better to design the outlines larger in relation to the em height.

If the font vertical metrics, for whatever reason, had to be based on Latin glyphs, then that certainly could result in some Thai base glyphs extending above the ascent (and certainly the cap height), and definitely would result in vowel and tone marks being positioned above the ascent.

I'm guessing context of the question was Latin-only (or only Cyrillic, Latin, Greek) fonts. But I imagine many will be facing similar questions when dealing with fonts that mix scripts with different vertical-space characteristics.

(Of course, in talking about vertical space, I'm assuming horizontal text layout.)

John Hudson · October 19

• The vertical metrics will affect default line spacing in many apps

...and will do so inconsistently across apps and platforms. And the same set of vertical metrics may also affect which parts of tall glyphs might get clipped, also inconsistently across apps and platforms.

John Savard · October 21

Thomas Phinney said:
Why on earth would we make fonts with diacritics, but ignore the needs of the people who use them?

That's a question that deserves an answer.

There are really two parts to the answer; one is about the "why", and the other is about the "needs".

Confining myself to European languages using the Latin alphabet with diacritics, these diacritics tend to be used mostly on vowels, which, in lower case, tend not to have ascenders.

If, in addition, using diacritics on capital letters is not very common, then it could be argued, or assumed (even mistakenly) that these Europeans don't really "need" fonts that stay within their assigned point size when accented capital letters are used.

I know that in word processors, I've observed the behavior that as soon as I use italics in a line of text in a single-spaced document, the line suddenly shifts in position, taking up more space than its nominal point size.

So this kind of crud - that if you do anything the least bit unusual, your word processor will insert leading to avoid the possibility of overlap - is considered to be tolerable.

Now to the first part. If it's a bad thing for a word processor to throw in leading when it may not be needed or wanted... what about a font that forces itself to be leaded all the time?

Back when I first encountered a laser printer, I was shocked that when I called for Times Roman 12 point, what I got looked like Times Roman 10 1/2 point. With 1 1/2 points leading, of course.

So: why a font may contain diacritics, including diacritics for capital letters, but not include the latter in the bounding box is because it's desired to have larger print for a given point size, rather than forcing printing to have the appearance of leaded type in order to account for any possible contingencies; and this temptation is yielded to because it seems the needs of diacritic users don't really include full support of diacritics on capital letters.

I'm not going to tell you you're wrong if you were to say that this reasoning is kind of stupid. But I can think of one factor that makes it excusable.

Some word processing or desktop publishing programs may allow you to specify that body copy is to have negative leading. But those that do have this feature, to my knowledge, don't have a way to give immediate feedback (that is, without previewing a test document) to the effect that "this much negative leading is perfectly safe if you don't use uppercase accents" or some other special features.

The root of the problem is the clash between how cold metal type, which was designed to be used by trained typesetters, worked and how fonts for use in computer word processing programs, designed to be used by secretaries or by just anyone need to behave in order to always work without worrying about complicated technicalities.

That's why I think that it's pointless to complain about fonts that put uppercase accents outside the bounding box; because what is needed are better ideas on how to address the fundamental problem.

John Hudson · October 21

The better idea is script- and language-specific vertical metrics settings in fonts, to enable appropriate default linespacing for different writing systems. I have been banging on about this for the better part of twenty years. Apple went some way to addressing this with script-specific metrics for some system fonts in their undocumented custom version of the BASE table. Even getting that documented and proposed for inclusion in the OpenType spec would be good, but ideally language-specific metrics would also be defined to e.g. allow for more generous linespacing for Vietnamese text.

Of course, we’d also need a proper implementation spec, because if there’s one thing that the history of font vertical metrics has taught it is that app developed will always find the wrong way to do it.

John Savard · October 22

John Hudson said:

The better idea is script- and language-specific vertical metrics settings in fonts, to enable appropriate default linespacing for different writing systems. I have been banging on about this for the better part of twenty years.

I will definitely agree that I should have been talking about vertical metrics, and not about the bounding box. I got the technical terms wrong; the bounding box should indicate what the character occupies; it's some vertical metric that defines the relationship between the character shapes and the point size.

Could anything go wrong with what sounds like an obvious idea? One thing I wonder is if some word processing applications only allow a global language setting, instead of letting you select text and choose a language option.

Then I could see a font that includes Chinese characters as well as the Latin alphabet having to place them within the narrower limits needed for English, and winding up with characters that are too small when the text is in, say, Vietnamese.

John Hudson · October 22

The thing you are worried about is already the case. Above, Peter Constable described the situation of having to squeeze Thai characters into the vertical metrics of Latin font layout. I had to do violence to several Indic scripts to fit them to the very limited vertical metrics of a user interface designed around the metrics of a particular Latin font.

Yes, there will be situations and software that is unable to handle script- or language-specific vertical metrics, but that just means we need sensible fallbacks, as we do already. Language-specific metrics require language tagging in documents, but could fall back to use locale and keyboard settings when not available. Script-specific metrics doesn’t rely on anything external to the text strings, since script is a character property that layout already uses.

Why ascender can't use interline gap, but diacritics can?

Comments

Categories