Hey Tim,

This was discussed a little while ago here: http://typophile.com/node/78036

The short answer is that it depends: on the designer's preferences, on the intended usage, etc. As you probably know that the more em the characters take up, the bigger the font will seem.

The general rule of thumb is something that you might expect: try to keep as much as you can in the em.

It also seems like a part of your question asks about spacing, or arranging the glyph horizontally in the em, and of course this takes up even more time than drawing the letters themselves when one is making a typeface.

Oh I also should add that going outside of the em typically doesn't have as big of consequences as it used to. Where as with older programs, if accents or ascenders went outside of the box, they would get chopped off, but more often than not modern programs—including web browsers—will display the entire glyph, inside and outside the em.

There are also other OT values you can set to give the font default line spacing, more info about that can be found in a useful PDF Karsten Luecke made and uploaded to his website: http://kltf.de/kltf_otproduction.shtml

Thanks Colin! I was sure the collective answer would be that it depends, and the thread you reference definitely speaks to the practical aspects of making these size/positioning decisions.

But I'm still curious about the aesthetic effects of making this decision with such pragmatism. Perhaps rightly so, it leaves balancing text blocks to the typographer ... but type designers have such astute sensitivity to letter and inter-letter proportions, I wonder if the em box factors into the (at least vertical) aesthetics of their work.

The em definitely does. In my last design I went through a whole bunch of proportion changes before settling on one that I liked—one that seemed full enough at text sizes without looking too large.

The proportion that you have inside the em effects default line spacing, how "big" your text is when set at a text size, and the OT values I reference in the second post also enable some control over the default values. The designer also can't go too small in the em or their typeface would look minuscule next to other fonts at the same size and require some adjustment on the behalf of the typographer.

So like many things in typeface design it is a balancing act, trying to provide your user with the best defaults but knowing some of them will be changed in the type setting anyway.

I don't really worry about the body of my letters. I got into type design late enough that most issues related to going outside the box were resolved and people had figured out that it's generally not good to have a caps height bigger than 700 em on a 1000 unit body. I also don't use any glyphs with stacked accents or design scripts with large flourishes. So for me it's a non-issue as long as I keep things under the 700 em height limit other designers established.

Thank you both.

It seems like the em box is an unnecessary abstraction. If typesetting applications allowed designers to specify font-size based on baseline-to-cap-height dimension, for instance, or other dimensions of the letterforms themselves, wouldn't that make more sense?

Or is there something I'm not thinking of, and there's a reason the em box is valuable?

That might make sense for western scripts, but in many non-western scripts the notion of baseline to cap height doesn't apply. Think of most of the Indian scripts, which hang from a headline, as opposed to rising from a baseline.

Jason C

With OpenType fonts there's a technical limitation I have to deal with. The maximum vertical size is 1200. The difference between the height of the Aring and the depth of the ogonek (or comma accent or descender) have to squeeze into 1200. I usually rescale the whole font to fit exaclty into 1200 after testing the accents. After scaling, my caps height usually ends up in the 700 range anyway. This way I can design accents that look good to me rather than trying to hit a specific target height.

Vietnamese accents require more planning to squeeze in without making the font look too small.

This is the first I've ever heard of a 1200 unit limitation on the vertical bounding box (highest element to lowest element across the whole font). Where did you get that from, Ray? I was just looking at my own Hypatia Sans, and the vertical BBOX is ~ 1360 total in the black weight....

Otherwise, I also second Jason's comment. The em square is needed because there is no design element that is comparable across all writing systems.

Cheers,

T

I'm guessing that Ray might be referring to the quasi-standard employed by some foundries that aims for the sum of OS/2 TypeAscender, TypoDescender and TypoLinegap distances to equal 120% of the UPM value -- hence 1200 units on a 1000 unit em --, and to the technical limitation that the sum of the Typo distances should equal the sum of the Win metrics distances to ensure cross-platform and cross-application compatible default linespacing. Taken together, this approach produces a default linespacing that is equivalent to 10-on-12 point leading, but require that all outlines fit within the resulting Win metrics to avoid clipping.

But neither of these are solid technical requirements or limitations, and there are good reasons to break both of them so long as one know what one is about.

About 8 years ago, rather than, you know, reading, I experimented and found the sweet spot where apps wouldn't clip. Some apps will clip beyond 1200, others will display it.

If you want to squeeze a font tightly into 1200 in FontLab:
Under Most Important Font Dimensions, sum up the 2nd & 4th Font BBox numbers, ignoring the minus. 120000 ÷ (your result) = scaling factor
Scale all glyphs with that scaling factor and the font should end up at exactly 1200.

"Some apps will clip beyond 1200"

Can you name some specific apps, platforms and versions? It seems to me that apps may have changed in the last 8 years.

About 12-13 years ago there were all sorts of issues with apps doing bad things with fonts that had too much kerning. We documented exactly which app versions had issues at the time. But the apps got over it, and today nobody much worries about having too many kerning pairs (or class-based equivalents) in a font.

T

I can't name any specific apps or platforms which clip above 1200.

All my fonts have been 1200 for under for the last 7 years or so; I'm not sure what apps still clip if any.

If not 1200, what's the maximum vertical resolution for OTF?

Ray, clipping is generally determined on Windows by the OS/2 table WinAscent and WinDescent values: so long as those values afre equal to or greater than the bounding box, there should be no clipping. Over the years, we've had to make some fonts like Cambria Math with very large WinAscent and WinDescent values to avoid clipping of the tallest glyps.

One thing to watch out for though is that a lot of apps also use WinAscent and WinDescent to determine default linespacing as well as the non-clipping zone, so if these values are high you will also get loose linespacing in some apps.

MS Word does sometimes clip shorter than the WinAscent and WinDescent values if particularly tight linespacing is applied by the user. This is because of the way in which Word draws lines of text.

I'm not sure how Apple determine clipping.

>If not 1200, what's the maximum vertical resolution for OTF?

for T1flavor the total ht allowed is 8000, TT flavor limit is 64k total, I think.

>It seems like the em box is an unnecessary abstraction.

One value must scale them all.

8000 huh? I'll give it a whirl.