The Em

dberlow's picture

This is an excerpt that started with my naïve attempt this spring at defining The Em for the wikidpedia, where someone called Mishka, well, never mind. The only other example I have of this problem, is in the "a bomb" (not A-bomb) and "the bomb" (as in a-bomb) situation, where "everyone" understands the difference...;)

...the type part is so "simple," it's best to concentrate on that, even if you have to start from....well, literally, there is "the origin," which is unfortunately not a good place to start!... What is the em? Not an em, or a em, ems, em quads or m&ms!...THE EM?
A. "An em is a unit of measurement in the field of typography. The unit is defined in the terms of a specific typeface, and thus varies in length." That Wikipedia! EM, can't phix it, can't quill it!
B. "The em is a sliding measure. One em is a distance equal to the type size. In 6 point type, an em is 6 points; in 12 point type an em is 12 points and in 60 point type an em is 60 points." well okay( Bringhurst), but that's both "The em, one em, & an em" in one definition.
C. "An em is the width of the cap height." E. Lupton
D. With all due respect, some of, some of the above ;)

"An Em" is the horizontal measure equal to the point size being composed in typesetting. When "an Em" is used as a spacing measure, it is shorthand for — " 'Typesetter'; give me a space along the line of text equal to 1 times the point size, please!" The vertical distance a typesetter moves, when the next line of text is desired, e.g. a carriage return, is usually the point size, plus some; like 12 point type with 2 points of leading, known as "12 on 14", this indicates that even though the type is 12 pt, the typesetter has moved 14 points down to start the next line. When the Typesetter moves down with no additional space, (known as "no leading", or 12 on 12), the vertical move is an em. If you move down two ems and start the next line, then it is double line spacing, e.g. 12 on 24.

The horizontal moves made by a typesetting system, including, an "em space", or an "em dash", are defined on a glyph-by-glyph, and font-by-font basis, ("I" being narrower than "M", or the em dash of a very wide face being wider than the em dash of a very narrow face, respectively, e.g. and not based on the "cap height"). If the font is a mono-spaced design, all horizontal moves are the same space, including an em.

All "That" uses the term "em" in the context of a given size during composition, and there it means "whatever the point size is times X" , so yes, "an em" is a sliding measure, but it is so because of the shorthanded nature of the command, and... it is not The Em. "The Em" is the amount of space on which a typeface design is converted to a font with the knowledge:
"This vertical space
represents the distance
the typesetting system
will move when the next
line below is located with
no extra 'leading' between
the lines of text."

This definition works for wood, stone, metal, film, bitmaps, and outlines. Modern font formats have definitions of ascent and descent from a baseline. As the total of these serve as the definition of the vertical move that used to be the Em, then that total is the new em.

Comments are welcome, or better yet, if you already agree, go hound Wiki for us...

dezcom's picture

The em is kinda like pi. It has an abolute value but relative to a sliding source.

ChrisL

Nick Shinn's picture

“A typographic unit of measurement with relative, rather than absolute value. It is a vertical space which represents the distance a typesetting system moves when progressing form one line of text to the line below, without the addition of extra leading.”

I actually think that "linespace" is better than "leading", because leading can refer to either the gross leading (em + extra leading) or the added leading. So in 10 on 14, the leading can be either 14 or 4. If you're going to talk about "extra" leading, you're automatically assuming that base leading = em height.

So another definition:
“A typographic unit of measurement with relative, rather than absolute value, equal to the built-in linespace of a font".

John Hudson's picture

Davud: “A typographic unit of measurement with relative, rather than absolute value. It is a vertical space which represents the distance a typesetting system moves when progressing form one line of text to the line below, without the addition of extra leading.”

Modern font formats have definitions of ascent and descent from a baseline. As the total of these serve as the definition of the vertical move that used to be the Em, then that total is the new em.

Eek! You've just thrown out the relationship between em and nominal point size. This isn't a sliding scale anymore: it's a scale that has slid right off the edge. Well done. I like it.

So when we include an em space or em dash glyph in a font, should we make its width equal to:

a) the UPM value (traditional em)?

b) the sum of the OS/2 winAscent and winDescent values?

c) the sum of the OS/2 TypoAscender and TypoDescender values?

d) the sum of the OS/2 TypoAscender, TypoDescender and TypoLineGap values?

I suppose it might depend on how one has set fsSelection bit 7? :)

twardoch's picture

Nick,

the built-in linespace of a font has nothing to do with em.

The em is otherwise called UPM size and is always equal to the point size. In a typical Type 1 font, the UPM size, or the em, is 1000 units. When the font is used to set type, the em, i.e. the 1000 units, are scaled to the desired point size. This means that at 10 pt type, the 1000 font units are scaled to 10 pt. So if your uppercase H is 700 units high, it will be 7 pt high at 10 pt type.

The built-in linespace of a font (linespace without extra leading) is typically the difference between Ascender and Descender. If the Ascender happens to be 750 and the Descender happens to be -250, then the built-in linespace is indeed 1000 units, so it corresponds to the em. But if the Ascender is 800 and the Descender is -300, the built-in linespace is 1100, so it’s 110% of the em, or 11 pt when 10 pt type is set.

I’m sure you noticed that when you set different fonts at 10 pt in some applications, they get different default linespacing. They wouldn’t if the built-in linespacing were always equal to em.

In OpenType and TrueType fonts, there are three different Ascenders and Descenders. Different applications and operating systems use different of these values. In Type 1 fonts, there just one such pair of values. But this is a technical detail in the context here.

Some applications don’t use the font-internal Ascender and Descender values at all to determine linespacing but use point sizes instead. Indeed, 10/14 pt type will always mean 10 pt type set of 14 pt linespace. But a “120% leading” may mean either 120% of the point size (120% * 10 pt = 12 pt) or 120% of the default linespace of the font (which may be, as I said, 10 pt or 11 pt or anything else).

Bringhurst is right and correct: “The em is a sliding measure. One em is a distance equal to the type size. In 6 point type, an em is 6 points; in 12 point type an em is 12 points and in 60 point type an em is 60 points.”

This is not true: “An em [...] is defined in the terms of a specific typeface, and thus varies in length.” For each typeface set at 10 pt, the em will be always 10 pt.

This is specifically NOT true: “An em is the width of the cap height.” The size of characters set at a specific point size (e.g. 10 pt) using different typefaces will be different. In many text typefaces used today, the height of the uppercase H equals 70% of the em, but that figure is only a convention and may differ between font vendors and between specific typeface styles. For example, in a font like Zapfino, the uppercase H is significantly smaller than 70% of the em.

As I explained earlier, this is completely wrong: “This vertical space represents the distance the typesetting system will move when the next line below is located with no extra ‘leading’ between the lines of text.” In some typesetting systems, the linespacing is based on values relative to the point sizes (that is, to the em), while on other systems, it is based on various Ascender and Descender values embedded in the font, which do not have any relation to the em. They may, but only by convention of specific font vendors.

Another issue is the issue of em space and em dash.

The Unicode standard has a code U+2003 that stands for EM SPACE. This character should nominally have the width equal to the em (i.e. to the UPM size) — typically 1000 units. However, the type designer may include a glyph of any width there, and some designers feel that an em space should be actually a bit narrower than the full em. On the other hand, some applications may enforce the width of the character U+2003 to be equal to em, and may not use the uni2003 glyph from the font at all.

Similarly, U+2014 is the character EM DASH. Traditionally, it was supposed to be a dash that takes the full length of an em, with no sidebearings. However, some type designers prefer to make the em dash a bit shorter and include some sidebearings.

Regards,
Adam

twardoch's picture

David,

I think I now understand your point of making the difference between "an em" and "the em". Now, I think in the age of digital typography, or even in the time of fototypesetting, it was and is futile to try to link the em to any VERTICAL measure. The em should only relate to HORIZONTAL measures. Relating em spaces, half ems, quad ems etc. to point sizes makes sense, because that is the only reliable measurement that works across fonts and applications. Even with Microsoft's relative point sizes, and Quark's point switchable between "traditional" and "digital", 10 pt is always 10 pt on the same screen, or in the same publication. So a 10 pt em is always a 10 pt em, and a half em is always 1/2 of the em.

On the other hand, vertical linespacing is just a mess. If creators of font formats were smart back in the 1980s, they would have only created one important measurement: the position of the baseline (on the em). If the em were 1000 units and the baseline were 250, then the ascender would be automatically implied to be 750 and the descender would be -250. And we would have the same reliable, "physically tangible" linespacing that we did in wood and metal.

But unfortunately, font format makers have gone overboard and created hhea.Ascender, hhea.Descender, OS/2.WinAscent, OS/2.WinDescent, OS/2.TypoAscender and OS/2.TypoDescender. There are five redundant values in the font, and absolutely no control over how linespacing is applied in different applications.

John Hudson's picture

...the position of the baseline (on the em). If the em were 1000 units and the baseline were 250, then the ascender would be automatically implied to be 750 and the descender would be -250. And we would have the same reliable, “physically tangible” linespacing that we did in wood and metal.

That's a very Latin-centric approach to font metrics. Not all scripts have the same typical arrangement that makes those figures convenient for a large number of Latin typefaces. If you tried design an Arabic naskh type on such an inflexibly defined body, you would need to make it tiny in order to squeeze the deep descenders into that 250 unit space, and would end up with gigantic white space above the letters.

twardoch's picture

No, you wouldn't. I'm not saying that the type would not be allowed to shoot over or under the body. Your glyphs could go as high as 2000 units or as low as -1000 units if you wished. But the linespacing would be controlled by just one value. Note that this is in fact how it is done today in high-end applications. In Adobe InDesign, if you specify leading in points, the OS/2.TypoAscender value is only used once — to determine the distance between the top of the frame and the first baseline. Then, each consecutive baseline is simply placed at the distance specified by the linespacing set in points. For example, if you set 10/14 using a font that has OS/2.TypoAscender = 760, then the first baseline will be placed 7.6 pt below the origin of the frame, and each next frame will be offset by 14 pt. What you set as TypoDescender or TypoLineGap doesn't really matter.

Of course, many applications don't allow the user to specify lienspacing in any way, or rely on some sort of "default" linespacing. Of course, it is a nice thought that the type designer can set the default linespacing for a typeface. In the world we live today, very few applications actually use the "typographically default" linespacing set by the designer, since other values (hhea or OS/2.Win) are used which are actually supposed to be used for other purposes.

But even if we at some point arrive at the point that all applications use the OS/2.Typo information (at least in the fonts with the OS/2.fsSelection field hacked accordingly), we will still face a complicated problem:

The default linespacing will still differ from font to font, thus making it difficult to mix fonts in one document (without the user taking complete control over linespacing by specifying it explicitly in points).

It is obvious that the wider the text column is, the more leading the text needs — the current system, and even the future system (based on OS/2.Typo plus fsSelection) have no knowledge of this.

The OS/2.Typo-based system is and will be useless for purposes of multilingual computing. Linotype’s Helvetica World font that you designed and produced is the best example for this. No matter which Ascender and Descender fields the applications uses, the one-value-to-serve-all approach will never be sufficient. The default linespacing optimized for Western European languages will be to tight for Czech and far too tight for Vietnamese, but will be too loose for Cyrillic.

The OpenType Layout system theoretically seems to have a provision for this. The BASE table specifies means to shift the baseline up and down depending on the script and language, and also allows you to define minimum and maximum "extents" for glyphs, depending on script and language. However, the specification does not explify how these extents should be used. Also, just as with the infamous OS/2.Win values, the specification seems to throw rasterization issues with linespacing issues together.

When reading the spec, one has the overall impression that Microsoft engineers were obsessed with the idea that ideal linespacing is such that the descenders of the previous line touch the ascenders of the following line.

Or maybe I'm just reading it wrong.

A.

Nick Shinn's picture

the built-in linespace of a font has nothing to do with em.

Sure it does.
The built-in linespace IS the UPM size, as you rightly point out.
We're dealing with a Wiki definition, so linespace = leading, and has nothing to do with the concept of "line gap", as FontLab terms it.

John, I generally eyeball my dash widths, taking my cue from the width of the space (again, that's eyeballed). After all, it's dysfunctional in a condensed or extended face to derive these characters' horizontal width from the vertical UPM value.

As the traditional "em" of metal type has become problematic, and the only place most people (other than letterpress folk) encounter it is in regards to the em dash and en dash, really just long and short dashes, perhaps there can be two definitons, a traditional one about metal type, and a new one:

"Em: denotes the longer of the two dashes in a font, similar in width to a capital M."

dberlow's picture

Thanks for all the input. This started with "numberous" aficionados pointing out that "all 12 pt types are not the same size anyway, so what's the points point?" I wanted to propose a "virus" that would scale all latin fonts so the Ascent was the y extrema of the H, and the descent was the y extrema of the p. Then, I decided to just to do it to my 10,000 favorite fonts, and see what broke on the MacMac Apps, then on WindowsMac Apps, and then on WindowsWindowsApps and then... I decided to go to the beach instead.

But it's still raining, so I decided to finish this. It sounds like: the number of definitions of "point", sizing in general, and more confused interpretations of character widths needs to come up to "speed" with the near-voodoo appearance to THE EM, before we can say with certainty that all the science there was in type design has been removed, or at least argued into enough competing theories that it can no longer be taught (if that's the word for "teached"? not "tighted"?:). The good news is, this confusion-at-the-core certainly makes it easier to claim there was nothing, and introduce a whole new "science".

But for the mean time, and assuming everyone knows now what "we" mean by "an Em" which is fine as a "sliding" or Pi-ing" or what-so-ever dez-finition, as long as the definition includes, "in the context of a point size", which is a context that all EM-containing word/word phrases, besides "the EM", should be in, I thunk.

“The EM: This vertical space represents the distance the 'typesetting system' will move when the next line below is located with no extra ‘leading’or 'linespacing' between lines of text. In 'modern font formats', it is usually expressed as the Units Per Em, which is then formulated into font scaling with whatever the typesetting system is using to specify size of the type, to arrive at a font of the user's choice. The Em is also used by the type designer to define the sizing of the letters relative to the "no extra leading or linespacing movement" made by the typesetting system. (In the context of a particular point size, see also "An Em", Em Quad", "Em—Dash" and "Em Square".

Clear, typographically?

twardoch's picture

“This vertical space represents the distance the ‘typesetting system’ will move when the next line below is located with no extra ‘leading’or ‘linespacing’ between lines of text.”

I really have a problem with this definition. Many modern applications simply DO NOT use the em as the measure for zero-leading linespace. Instead, it uses the distance between Ascender and Descender. This distance often is different from the em. For any given font, the em at 10 pt will always be 10 pt, but the "built-in linespace" can be 9, 9.5, 10, 10.5, 11, or 10.235 pt.

The question of LineGap is a fully different one.

A.

Bert Vanderveen's picture

IMHO Em has nothing to do with vertical sizes or proportions. In Art School we learned to set type by hand and the Em (or "vierkantje" in Dutch, eg "square") was the body size squared. You'd use an Em to indent.
Half of an Em ("halfje") was an En.

Try to improve upon the old ways… ; )

k.l.'s picture

and the Em (or “vierkantje” in Dutch, eg “square”) was the body size squared

... which establishes a relation between height and width.

Semi-off-topic, but for it's already been touched:
What I find a bit odd is making en and em dash 1/2 or 1 UPM wide. To me this looks too wide in most cases. However, it would make sense to have 'en' and 'em' dashes which have tabular numeral and double tabular numeral width, to be used in tables only. But I have no idea which feature may be appropriate. Placing the substitution in tnum and pnum would replace them in text too -- which is what I'd like to avoid ...

dezcom's picture

It appears to me that Americans use a wider em dash in general than some European countries. I find that the eye is the best judge but this leaves the question open to who's eyes.

ChrisL

William Berkson's picture

Karsten, Chris, see this on-going thread for discussion of the national differences and what is preferable for the em-dash: http://typophile.com/node/27727

David, reading this discussion I suspect there is no way to achieve your goal of a simple, single definition of THE EM that suits all output devices--old letterpress and digital-to-offset and screen--and all applications. So it may be simpler to define the 'the metal em' 'the digital em' etc.

A bash at it:

In metal foundry type the EM is the body size (height) of a piece of type in a font, and is also normally approximately equal to the width of a cap M.

In digital type the EM is the square grid upon which glyphs are drawn and encoded. A glyph may overlap the em. The latin cap M with sidebearings normally is drawn to roughly this width, and the latin ascender plus descender roughly this height.

When the digital typeface is printed this EM is used as a unit to scale the output. The side of the EM square in the computer drawing equals the number of points specified in the application for printed output, each point being aproximately 0.0138 inch or 0.3527 mm. For screen output, size of a 'point' is not uniquely defined across applications and machines.

[I don't know if this needs modification for bit map fonts.]

Nick Shinn's picture

Many modern applications simply DO NOT use the em as the measure for zero-leading linespace.

YES they do. If you set 14 on 14 in Word, that's what you get.
If you use the default non-numerical line spacing, you get the extra 20% or whatever, but this is nowhere defined in relation to leading, and you can't add leading to it. It is non-leading linespace, which is not the same as zero-leading linespace.

k.l.'s picture

Karsten, Chris, see this on-going thread for discussion of the national differences

Oh, didn't notice that this turned into a more general thread.

John Hudson's picture

Nick, Adam's choice of the term 'zero-leading linespace' might have been inappropriate, but his basic point is sound: in user experience the distance between the baseline of one line of text and the next is most often not determined by the em (i.e. nominal body height). Only in professional page layout and design apps is linespacing specified, by default, in terms of leading. In word processing applications and in CSS driven websites it may be an option, but in almost all other apps there it is not even an opion. In text editors, spreadsheets, databases, and in the default behaviour of word processors and browsers, linespacing is determined by font vertical metrics, and that is not a standardised '20%' linespacing. On Windows, almost every application determines default linespacing by combining the OS/2 WinAscent and WinDescent values. Since these values were originally specified to define glyph extents (to avoid clipping), not to define linespacing, they are almost always larger than the em height and determined by the highest and lowest outlines in the font.

So in a situation in which the linespacing most often encountered by users -- and by readers of wikipedia entries -- is determined by something other than the em, it seems misleading to equate the em to the distance between lines of text. David's suggestion is logical if one knows quite a lot about how fonts work, but it doesn't seem to me very helpful for a general reader.

Nick Shinn's picture

nominal body height

Works for me.

twardoch's picture

> nominal body height

For me not, because it doesn’t say anything. It presumes the knowledge what "body" means in typographic terms, and "nominal" suggests that some external entity defines a convention ("names" it).

It is really very simple: the em is a unit of typographic measurement that is equal to the point size of the type used in the text.

No more and no less. Linking the em to the linespacing is artificial, and only works in some limited context. It is true that the "built-in" linespacing of a font *sometimes* equals the em. But the point size *always* is the em, and that's the only thing that one can reliably say about it.

:)

A.

dezcom's picture

The power of em-inent domain.

ChrisL

dberlow's picture

I think defining from the carriage return (my wiki attempt), "forward" to line spacing and "back" to the type designer's sizing decision requires a general reader to know only what they can see on the screen, the cursor, the CR, the type, and not more.

The intent of the definition I laid down here, was to link the average user experience, to the application/OS's presentation, and to the type designers marks. It's possible to point out that the definition is flawed because "somewhere" in the real world it "doesn't work," sure...but trust me, it ain't the definition that's the problem. lol

If you *are interested* in starting somewhere, from where you can proceed towards understanding the process from type design to use, as well as to point out technologies, apps, fonts, designers, speakers, organizations and publications that/who do/say otherwise, and why, then I'm all set thanks.

Nick Shinn's picture

the em is a unit of typographic measurement that is equal to the point size of the type used in the text.

But that's not true. People (other than those in letterpress) don't use ems for measurement, certainly not where it's most apparent, in the em-dash, which in practice bears no relationship to point size.

John Hudson's picture

But that’s not true. People (other than those in letterpress) don’t use ems for measurement...

Actually, it is used quite extensively in CSS. One can design scaleable websites entirely in terms of em, which means that they scale relative to the size of the body text type size. One can also define linespacing in CSS in terms of em, e.g. 1.25 em. It is actually a very intelligent way to build scaleable websites, and it is all based on the em being equal to the nominal point size of the body text.

twardoch's picture

> People (other than those in letterpress)
> don’t use ems for measurement

Actually, people do. For example, in German and Polish typography, the typical paragraph indent prescribed by the typesetting manuals is one em (in German "Geviert", in Polish "firet"). Other values, such as recommended column widths, column gaps, are also based on the em.

Not many people use barleycorns as unit of measuring the length, and yet it is one such unit. And I'm sure it does have its use, in a limited context.

A.

twardoch's picture

The em is not equal to each em-dash, but in approximation, or in many cases, it is. Similarly, the mechanical horsepower as a measurement unit does not equal the operating power of every horse in the world, but it is an approximation.

twardoch's picture

(Needless to mention that the em is rather rarely equal to the width of "M", but somehow, the term has been coined.)

Nick Shinn's picture

it is used quite extensively in CSS

Is that the real em based on point size, or the other one, based on WinAscent and WinDescent?

I note that one can also use "exs" in CSS as well as "ems".

Speaking of horsepower, horseheight is measured in hands (four inches).

John Hudson's picture

Is that the real em based on point size, or the other one, based on WinAscent and WinDescent?

The em equal to nominal point size. As far as I know, no one actually uses the term em to refer to linespacing as determined by OS/2 table metrics; that is just a possibility -- perhaps a likely conufusion -- suggested by David's initial proposition.

twardoch's picture

> Is that the real em based on point size,
> or the other one, based on WinAscent and
> WinDescent?

Nick,

there is only one em. There is no "other one". The distance between the ascender line and the descender line -- no matter which lines we take as reference -- is not the em.

A.

dberlow's picture

AT: "the width equal to the em (i.e. to the UPM size)"
Define the UPM please, but whatever you do, please, don't use the word "EM", okay? :)

Nick Shinn's picture

there is only one em.

Let me rephrase: is the "em" used in CSS the real em (point size, UPM), or the WinTel "em", defined as ascender line to descender line?

John Hudson's picture

Define the UPM please, but whatever you do, please, don’t use the word “EM”, okay?

UPM = the number of units that define the height of the scaleable cartesian grid on which the outline of glyphs in a font are plotted.

John Hudson's picture

Let me rephrase: is the “em” used in CSS the real em (point size, UPM), or the WinTel “em”, defined as ascender line to descender line?

There is no 'WinTel' "em"'. Em is a measurement equal to the nominal point size of a font. That is how it is used in CSS and everywhere else.

bieler's picture

Traditionally (metal type), the "real" em is the square measure of the physical body of the casting, it has less to do per se with the visual size of the represented typeface itself, since this differed. But a 12-pt em is a 12-pt em, and so on, no matter what is on it. Glyph or not.

Digitally? Well, em squares can easily be worked out with a little effort. If at all that important.

Gerald
http://BielerPress.blogspot.com

dberlow's picture

"UPM = the number of units that define the height of the scaleable cartesian grid on which the outline of glyphs in a font are plotted."

So, that makes the EM a vertical measure.

Bert Vanderveen's picture

Just to complicate this discussion some more:
Monotype (and its licensees) used to do custom casting, eg a 11pt Bembo on a 13pt body (just an example!). That would make the em-value 13pt for that size of particular type (in the physical sense — the non-printing ems and ens and so on would be 13pt, 6.5 etc. wide — we're still talking about lead). So you can't really state that Em is inherently related to any measurement of any typeface.
(I remember this because quality typesetting in the Netherlands was mostly Monotype-based and a designer had to take in account these variables, because eg spacing caps for titles required the use of the various kinds of spaces and you needed to know the exact measurements for that.)

But to simplify things I'm willing to go for the following definition: an Em is a horizontal measure equal to the bodysize of a typeface.

The fact that webdesigners have seized the Em as a unit for their own wizardry is moot — that's a completely different kind of sport.

dberlow's picture

"custom casting"

Building the leading into the face to save time does not change the point size or the definition of "the em." It only changes the proper selection of "an em" when spacing is required in either dimension.

"So you can’t really state that Em is inherently related to any measurement of any typeface."

Nobody did. I think the point is that if you can say anything about the relationship of the Em to all faces, it is valuable, and if you can't then what's typography anyway? :-)

John Hudson's picture

So, that makes the EM a vertical measure.

Internally to a font, that is its function. In typesetting it is also used, perhaps more commonly, as a horizontal measure. But it is agnostic about directionality really: you can measure in ems vertically or horizontally (certainly within CSS it is used in both directions). There is no a priori reason why it shouldn't be used as a diagonal measure.

John Hudson's picture

I think the point is that if you can say anything about the relationship of the Em to all faces, it is valuable, and if you can’t then what’s typography anyway?

What you can say about the relationship of the em to all typefaces is that an em relative to a nominally 10pt type size will be 10pt, and relative to a nominally 11pt type size will be 11pt, etc. and this is independent of the actual size of the letterforms at those nominal sizes and is independent of any built-in linespacing provided by font vertical metrics or being cast 'small on the body'.

Nick Shinn's picture

I think I've exhausted my devil's advocacy (cue Dezcom pun...)
Can we vote now?
Or does Adam still have a problem with John's use of the term "nominal"?

John Hudson's picture

I think Adam was objecting to 'body height' not to 'nominal'. Of course, nominal type size and nominal body height are identical -- and usually invisible in the output regardless of type medium -- but body height is a specialist term.

twardoch's picture

Bieler wrote:
> it has less to do per se with the visual size of the represented
> typeface itself, since this differed

It still differs. 12 pt Zapfino uppercase H is surely of different size than 12 pt Arial’s.

David wrote:
> So, that makes the EM a vertical measure.

Well, sure, but one that cannot be easily meaured physically. 12 pt type means that some chunk of vertical space is 12 pt high.

Onto that chunk of vertical space (em), some glyphs are drawn, but their physical size can be completely arbitrary -- only by a convention of some font vendors (first of all Adobe), in most of their text typefaces, the height of flat uppercase letters (e.g. "H") is 70% of the em.

When lines of text are set, the distances between chunks of vertical space (ems) differ. If the linespacing is truly equal to one em (e.g. in CSS), then the distance between two consecutive baselines is indeed one em. Some professional typesetting applications also base the linespacing on the em. Other applications use different information to determine default linespacing, most prominently the OS/2.WinAscent-OS/2.WinDescent distance on Windows, hhea.Ascender-hhea.Descender distance on Mac OS, and OS/2.TypoAscent-OS/2.TypoDescent in some Adobe applications.

John,

you’re right that I objected to the term "body height". Since the "body" in digital fonts is not really palpable, I prefer not to use it. How about this:

In digital typography, fonts are designed on a cartesian coordinate space. Outline point positions and all metric information are measured in so-called "units". A square on that space of a specific size (usually 1000 units) is referred to as an "em". When a text is set at a particular point size, the font is scaled so that the em is equal to the point size used.

dberlow's picture

John: "UPM = the number of units that define the height of the scaleable Cartesian grid on which the outline of glyphs in a font are plotted."
...sounds utterly reasonable but it is utterly wrong because the em is a subset of the "grid" and this "definition" says the glyphs are plotted on the UPM.

The Grid, is 16k something square defined in TT. If you make your EM 256 x 256, you can hang out "a lot". If you make your grid 16,000-somethingX2, you can't hangout at all. That's how that works, that's how that is defined.

Without defining the relationship between the EM and the composition systems, you have no definition for The Em, or the subset of the grid that is defined by upm. Because we have a "definition" for "an em", some people think they know how to define the em back from that, which wrong, or at least it don't work in composition in several ways.

If you read this, John:
http://www.microsoft.com/typography/OTSPEC/TTCH01.htm
It gives "my" definition of the em, nearly exactly. Now I'm not sayin' they're always right...

paul d hunt's picture

i think that Adams explanation is the clearest and makes the most sense.

dberlow's picture

"i think that Adams explanation is the clearest and makes the most sense."

State it please.

paul d hunt's picture

EM = UPM

dberlow's picture

Or UPM=EM

Adam: "OS/2.TypoAscent-OS/2.TypoDescent in some Adobe applications."

Don't all Adobe applications use on of the three?

John Hudson's picture

David, this was Adam's formulation, at the end of his last message:

In digital typography, fonts are designed on a cartesian coordinate space. Outline point positions and all metric information are measured in so-called “units”. A square on that space of a specific size (usually 1000 units) is referred to as an “em”. When a text is set at a particular point size, the font is scaled so that the em is equal to the point size used.

John Hudson's picture

…sounds utterly reasonable but it is utterly wrong because the em is a subset of the “grid”...

I used the term 'scaleable grid' in an effort to succinctly express the idea of the em as the subset of the grid that is scaled during type sizing, but I agree that it is unclear and I tried to compress the idea too much.

...and this “definition” says the glyphs are plotted on the UPM.

No it doesn't. It says that UPM defines the number of units of a grid that is scaleable, and that the glyphs are plotted on that grid.

At some point in this discussion, we might come to the conclusion that not everything can be given a definition that is different from a complex description, or that a more succinct definition isn't actually useful.

paul d hunt's picture

David, this was Adam’s formulation

i think David wanted me to explain what that was in my own words. I think he wanted me to try to prove how simple/hard it is to define what the Em is.

Syndicate content Syndicate content