Family x-Height
mauro sacchetto
Posts: 353
I have noticed that for certain fonts, within the same family, the x-Height (and to a lesser extent the C-Height) for the various styles are not always the same. Is this a sign of unaccuracy?
I find myself in front of a font with really anomalous heights:
Roman | Bold | Italic
-------------------------------------
x-Height | 422 | 413 | 437
C-Height | 699 | 700 | 699
This is slightly noticed in 10-12 point printing, but here is a 1000% image:
Is it convenient to work on these differences to eliminate them and make everything homogeneous?
I find myself in front of a font with really anomalous heights:
Roman | Bold | Italic
-------------------------------------
x-Height | 422 | 413 | 437
C-Height | 699 | 700 | 699
This is slightly noticed in 10-12 point printing, but here is a 1000% image:
Is it convenient to work on these differences to eliminate them and make everything homogeneous?
0
Comments
-
Depends on the design. Each memeber of the family is its own thing within the larger picture. I tend to give bolder weights some additional room above so it doesn't get too crowdy.
But the 699 seems like a bug.
0 -
Each member of the family is a member of the family.
Darker weights need a bigger x-height to look the same.0 -
699 a bug respect 700?
But the most relevant difference concerns the lowercase (and small caps), so that a certain difference is visible even with a size of 12 pt. If even the aesthetic principle is right that every family member has his own character, is it not excessive to jump from 413 to 437?
0 -
I’ve made the x-height of Bold taller than that of Regular in several typefaces, as per Hrant’s observation. But beyond that…
…the idea that glyphs should conform in x-height is routinely adhered to in current type design, a consequence of Postscript Type 1 alignment zones, which were configured to temper artefacts at body text size in the low resolution of early digital media, artefacts now largely obsolete.
[Title page of a book published in the 1920s. The type is a Garamond.]1 -
Therefore, from an aesthetic point of view, is this situation still acceptable?
Note that the Bold is the lowest and that the differences are really relevant in cases like the <i>, the <p> and the <t> Italic. The graces of letters like <u> <v> <w> or <x> are almost as many evidently not parallel.
0 -
Something to consider: because slanting makes stems longer, some people compensate by making extenders shorter and/or the x-height taller.2
-
But, speaking immediately, do you find these measures proportionate? There are "failures" that I do not find in other Garamond (Adobe's Premiere or EB Garamond ...)
I find certain irregularities strange: the baseline of <x> is more or less the same, while that of <w> is obviously different. In this way a text could look like "roller coaster" ...0 -
Hrant H. Papazian said:Something to consider: because slanting makes stems longer, some people compensate by making extenders shorter and/or the x-height taller.1
-
In the two graphics shown by Mauro, the nominal/measured x-height differences for the italic are really a difference in overshoot, not so much a difference in x-height. It is an optical issue: those tightly curved serif/terminals get more overshoot to look the same effective height.9
-
I theorize that we are aware of both the absolute size of text letters and their size as “stroked paths”—i.e. linear shapes which have thickness.
Who knows, perhaps we also factor the size of the counter into the mental equation.
At any rate, slightly increasing the x-height of Bold serves to balance the various perceptual algorithms we’ve been born with and have subsequently trained, so that different weights appear to be the same nominal size of font, or at least harmonize in a layout.
6 -
Of course, we know that the geometry of a form and its perception are different things. I think Thomas's suggestion is excellent1
-
Practical considerations in the heaviest weights can effect x-height. The crushing of heavy e, s and a are always a puzzle and one solution is increasing the x-height. The top of a heavy T gets thick and can cause unpleasant alignment situations with the lowercase which might be corrected by adjusting the x-height. The interplay between f, t and z and the battle with congestion on the top the f can inform x-height decisions.7
-
@Hrant H. Papazian To my eye, this lengthening of slanted extenders effect is more noticeable in rounded sans typefaces. If you look at oblique or italic rounded sans where the ends are circular you can see it a bit. Well, I think I can see it. I don't see the same effect when the ends aren't circular...like in the case of an oblique with a mechanical slant where the ends become skewed ellipses.2
-
Do you agree that the baseline, x-height, and other type measurements are, for the most part, imaginary lines? With the provision that they can be easily deduced for most modern type. But take for instance Textura Quadrata, where every glyph has in fact overshoot... and you got yourself a puzzle, positioning a baseline is somewhat arbitrary. Placing it where typical letters like i, m, n have their apices is one solution, but I like to think it is best to level the whole font so that it appears to sit on the same baseline as flat-bottomed letters that might not even appear in that font, but a different one.3
-
Consider that the font might be used with others on the same line. In that case you’d want the baseline to be set allowing the appropriate overshoot, so it may well be that no single node in the entire fonts sits on it.
Edit: Sorry, I think I just repeated what Adam just said.0
Categories
- All Categories
- 43 Introductions
- 3.7K Typeface Design
- 803 Font Technology
- 1K Technique and Theory
- 622 Type Business
- 444 Type Design Critiques
- 542 Type Design Software
- 30 Punchcutting
- 136 Lettering and Calligraphy
- 83 Technique and Theory
- 53 Lettering Critiques
- 485 Typography
- 303 History of Typography
- 114 Education
- 68 Resources
- 499 Announcements
- 80 Events
- 105 Job Postings
- 148 Type Releases
- 165 Miscellaneous News
- 270 About TypeDrawers
- 53 TypeDrawers Announcements
- 116 Suggestions and Bug Reports