Typophile

Who can give a scholarly definition of "type size"?

Uli Stiehl

A text typeset in 9 on 10 point using font A may look, as if it were identical with the same text typeset in 10 on 10 point using font B. This phenomenon is exemplified by me in this document:

http://www.sanskritweb.net/temporary/helve90.pdf

Who can give a scholarly definition of the notion of “type size” (or “size of type”, “font size”, “point size”), taking into considering this phenomenon as exemplified above.

Type size at output is controlled by two factors.

One is the relationship between the glyphs and the em square, the default space upon which all glyphs of all fonts are defined and positioned. This definition and positioning of glyphs at a single scale, is done by the type designer, so that all output of a given size of a font will be compatible across all glyphs.

The other factor is the size input by whatever method is offered to the user, so that the user may control the size(s) of the output. The first factor is non-standard, or, not all font families share the same relationship to the em square. The size relationship to the em square should, however, be standard across the styles of a family. The second factor has multiple standards, but the predominent one is the point system, (72.289, or so, to the inch).

This second factor allows the user to define consistent measure from baseline to baseline between any two fonts of the same size and leading, regardless of the first factor, or size on the em. But the first factor often causes baseline to cap height, e.g., variation within the same point size across font families.

From the energetic use of the two factors, both confusion and completness are found, somewhere.

Cheers!

This is implied by David’s excellent explanation, but I wanted to further emphasize that the notion of “point size” which you refer to, should not be considered an absolute measurement. The only true absolute measurement within a font is the pixels per em size (ppm).
You can request 10 point type, but the number of pixels used to represent the height of the capital “H” will still vary, depending on whether you’re displaying 10 point on a 96dpi display, a 72dpi display, a 600dpi printer, etc etc. The ratio of the em square to the cap height (and other height zones) within the font will remain roughly the same in each of these scenarios, but it won’t be exactly the same. This is mostly due to the effect that hints can have on glyph height zones.

There are 2 factors that determine the exact ratio of height to em square, displayed ultimately as some number of pixels. First, the outline is scaled, as David described, by scaling the height of the font (which could be derived from several different values, but that’s a complication for another discussion), with the outlines scaled proportionately. Then hints are applied. Remember that hints are specific to a ppm size not a point size (since they need to be related to an absolute value.) You could potentially have hints within a font that nudge x heights, cap heights, descenders, etc, by X number of pixels at Yppm size. This will normally only happen at display sizes, but could happen at up to 72ppm.

Hmm, I suppose you’re sorry you asked by now! But this might help explain why you may see variations in cap height to x height ratio, or cap height to em square ration, at different smaller point sizes.

thanks,

Jason C

The classic definition is the distance from ascender to descender, with the caveat that real fonts don’t necessarily conform to this. When fonts were metal, it was the height of the slug. Sometimes there would be a little more room on the top and bottom, by design or by necessity. The software equivalent of that block of lead is the em consisting of 1000 units. Type is sized according to that em, relative to which all the glyph outlines are drawn. If the type designer draws the glyphs smaller relative to the em (possibly out of a worry that diacritics on capitals could collide with descenders at zero leading), a 10pt setting of it will look smaller.

I very much appreciate the technical comments by Mr. Berlow and Mr. Campbell, but it seems to me that I was not correctly understood. Therefore I added an additional page to the document as the last page

http://www.sanskritweb.net/temporary/helve90.pdf

Both “Helvetica” words on the last page are congruent, i.e. have the same mathematical size and shape, but they are typeset in different point sizes. Therefore the definition of “type size” is tricky here.

Uli, what I think may be puzzling you is that a face may be ’large on the body’ or ’small on the body’. In the case of metal type this meant the height and depth of the type relative to the vertical dimension of the metal slug.

In the case of digital type, the ascender of the h + descender of the g may be less than the digital em. And the height of the A ring, for example, may take the extremes of the characters beyond the limits of the digital em.

It looks like in your examples of Helvetica 90 and 100, these are simply scaled differently in relation to the digital em. Then boosting the point size and reducing the leading in your application program can get the size and leading of the 90 and 100 to match. As David explained, the final result comes from the combination of the inbuilt size together with the user specified size.

If you look at it in a font making program like Font Lab, it will take the mystery out of it. You will see how the upm is defined (typically 1000 or 2400), and where the character outlines fall on the grid. Your application program will interpret the character point size and leading—distance from baseline to baseline—according to the user specification of the upm and baseline.

“Both “Helvetica” words on the last page are congruent, i.e. have the same mathematical size and shape, but they are typeset in different point sizes. “

Thank you for the example. I think the terminology you are using in describing the phenomenon you see, is backwards. I would say, both samples are typeset in the same point size, but they do not have the same mathematical size and shape. You might also say, the two samples were set at the same mathematical point size, but are typesetting at different sizes.

In this particular instance, it might be assumed that URW, who produced Nimbus, decided to scale the whole face to fit the accented uppercase into the Em, a common practice, and the first kind of sizing I mentioned.

“The only true absolute measurement within a font is the pixels per em size (ppm).”
You are heading out of type space and into device space though it counts eventually, this issue, is size measurement across fonts.

Cheers!

Uli, I don’t think it is possible to come up with a scholarly definition of type size. The phrases you listed are not specific enough to be defined in any absolute way. Forty years ago when I started messing about in type, the meaning was pretty clear. It was whatever read-off my line gauge when I hooked it over the top edge of the piece of metal I had in my hand.
Body size, cap height, and x-height all refer to something specific and unambiguous. However, today type size and point size do not. Type size is whatever you choose to measure and point size is that something measured in points. Although, generally speaking, the terms you asked about refer to the notion of body size, where body size is understood to be the native (unleaded) vertical measurement of the font including, in the case of metal type — which is the only place such measurements make any sense at all — all glyphs/strokes/elements that will be set from that singular font. Here font refers to a set of mechanical pieces used to produce printed letters of one style and a pre-determined system of vertical alignment and lateral spacing of those glyphs/strokes/elements.
Two years ago, I asked a similar question about why on earth when some digital fonts are set solid do descenders collide with ascenders of the subsequent line. I received an answer that included the phrase “large on the body,” which I understand as a possible reality in type setting, but fail to understand as a desirable aspect of a system for the reproduction of letters.
Thus, any definition of type size will depend on whether you are talking about the system to control the size of the letters to be produced, the letters produced, or even some part of the letters produced. Take your pick and stick with it.

“Two years ago, I asked a similar question about why on earth when some digital fonts are set solid do descenders collide with ascenders of the subsequent line. I received an answer that included the phrase “large on the body,” which I understand as a possible reality in type setting, but fail to understand as a desirable aspect of a system for the reproduction of letters.”

1)

That nobody can supply a satisfactory definition of “type size” is due to the fact that the digital font formats (PS Type 1 etc.), have been primarily developed for American font users only with the consequence that, for instance, nowadays in European languages (French, German etc.), it is no longer possible to “set solid” (e.g. 10 on 10 point) without time-consuming experiments.

see http://www.sanskritweb.net/temporary/solid.pdf

2)

Are “large on the body” and “small on the body” also applicable to non-American fonts?

see e.g. http://www.sanskritweb.net/temporary/body.gif

Is the font depicted here “large on the body” or “small on the body”?

In my view, such notions do not make sense for non-American fonts.

>In my view, such notions do not make sense for non-American fonts.

In digital fonts ’large’ or ’small’ on the body is just a question of how the glyphs are scaled in relation to the em. ’Larger’ or ’Smaller’ is in comparison to other fonts in a similar script. It is not a matter of the nationality of the designer. It is true that many fonts today have the height of the A ring or A circumflex greater than the em—a common recommendation is that the total of highest and plus lowest points are up to 20% greater than the em. This is based on the default leading in many applications, including Microsoft Word. See this for a detailed explanation.

Therefore many digital fonts will not set solid without clashes in the diacritics—they often need something between solid setting and 20% leading to keep the highest diacritics clear of the above line of text. Some script fonts have swashes that greatly exceed the em—by more than 20%.

You seem to want all fonts scaled on the em so that they can set solid, as was the case with metal. But what is so sacred about setting solid? If you rescaled the font by 80% in font software, regenerated it, and put the point size in the application 25% larger you would get the same result. Isn’t what matters what is on the page or screen?

>it is no longer possible to “set solid” (e.g. 10 on 10 point) without time-consuming experiments.

If you don’t want time consuming experiments, you can’t set type well—at least not without a lot of experience, which amounts to the same thing. Fonts, whether in metal or film or digital, have never had the same apparent size at the same point size. This has to be taken into account by the designer wherever you are in the world.

>Is the font depicted here “large on the body” or “small on the body”?

You can’t answer the question of how big a font is on the body by one line. It doesn’t matter whether the font in question is latin, greek, arabic, and indic script or whatever. But you can answer by looking at it in font software, or by setting it on successive lines with highest and lowest extending characters—provided you know what rules your application software follows. And the question does make sense in any script. It doesn’t matter whether the designer is American or German or Indian. The question is the scale of the glyphs relative to the digital em.

Mr. Bergson:

> Word. See this for a detailed explanation.

The “Update to the update to the update” clearly shows that the “vertical metrics” is a mess. Even Apple and Microsoft application programmers do no longer know what is meant by what metrical values.

> The question is the scale of the glyphs relative to the digital em.

Could you please give a concrete numerical example for what you mean by “digital em”?

As mentioned by me, the plain Roman style of good-old Helvetica (HelveticaLTStd-Roman.otf) has the x-y bounding box of (-166, -225) to (+1000, +931) and uses a 1000 units per em grid. The glyph of “A ring” has the top-most value +931, and the glyph of “c cedilla” has the bottom-most value of -225.

Using these numerical data, please give the exact dimensions of what you call the “digital em”.

>the “vertical metrics” is a mess.

I agree. This mess seems to be a legacy of the old ’font wars’ with different standards for Windows, Mac, PS1, True Type, and now open type. I understand that such messiness is typical in the software industry.

>Could you please give a concrete numerical example for what you mean by “digital em”?

The font contains a number called the “font upm value”. In Font Lab you can navigate: Font Info/ Metrics and dimensions/ Font UPM Value. It is commonly either 1000 or 2400. Thus the em is really a unit of measurement within the font such that ’one em’ is either a 1000 units or 2400 units, and the nodes, handles and metrics of the font are specified in terms of whole numbers of these units.

What is confusing here—to me at any rate—is that the digital em is not defined as a box going from one place to another in the glyph window. You can’t say “the em in this glyph starts here and ends here,” as you could in foundry metal type—it was generally just the height of the metal slug.

But in fonts the ’em’ is just a unit of measurement. The ’em’ isn’t a thing that starts at the lowest descender and goes to the highest point in the tallest character. That’s got another name—’bounding box’ I think, but I’m not sure. And the ’bounding box’ may measure more or less than one em—and thus be “bigger or smaller on the em.” It would really be better to say “bigger or smaller as measured in em units.”

What happens that complicates things is the different applications may define the ’top’ of the font differently. For example, I think Adobe puts the top of the text block at the ascender height. But another application might take the cap height or the highest point in the font.

What all applications are *supposed* to do, anyway, is to make it so that if you specify the font size at ’12 point’, and specify the leading as zero points, then when you print it out, it should physically be 1/6 of an inch from baseline to baseline on the paper.

So that’s what the ’em’ really is: it is an instruction to scale the output so that the ’em’ as defined in the ’upm’ value is printed out at the correct physical point size as internationally defined.

Thanks, I think I now understand this myself!

The answer to your original question is no. No one can give a scholarly definition of “type size.” What a scholar could do is chronicle all the different ways the term “type size” has been used. It would be a longish chronicle.

BTW, the digital era is from 1990 to 2008 — or, if you include the likes of the Linotron 202 in “digital” as opposed to “photocomp,” the mid-1960s to 2008. Even 48 years covers only about 10% of the period of “movable type” in the west, and that ignores China.

So — just trying to get a grip on this myself — does this mean that a 12 pt specification of a given font in QuarkXpress could lead to a different sized output (to paper) than the same size and the same font output from, say, InDesign? And, if so, does outputting to an intermediary format like pdf introduce any further uncertainty?

Where the top of the text box is in relation to the type might change in different applications—and hence the location of the printed output—but the size of the printed output should not.

If you specify 12/12 pt type in the application, the printed output should always have the baselines 1/6 inch apart.

OK, so let me see if I have this:

The size of a glyph is relative to the size of the em. The size of the em is however an absolute size because there is something in every program which will interpret it to give the same output as some other program operating on that input. (What might change is the calculation of the placement of the text block.)

Let’s assume, you make a printout on paper of the last page of the PDF

Captured from web.archive.org on 13 Oct 2008. view this capture