Accents part of the 2048/1000 limit?

Lila Symons

Saw this on twitter today and thought I would ask about it on here because I've never got a clear answer:

Type designers: How do you decide the size of your type on the "body"? Do you just use the full 1000 upm, ascender to descender? -Dave Foster (@ fostertype) 

Making sure that the whole letter (including accents) is in the 2048/1000 upm space can be ideal because designers are often building templates where the type has to fit in that space. Having parts of the typeface get cut off could be problematic.

I feel the only exception could be swashes that go beyond the ascenders and descenders. In those instances, I have done what Karsten Lücke suggests: http://kltf.de/downloads/FontMetrics-kltf.pdf

Chris Lozos

Uppercase diacritics almost always go above the full body height.  Cap diacritics are often sized down vertically to somewhat limit their intrusion into the space of the line above. Languages like Vietnamese which has stacking diacritics may need more leading than English or French.

Ray Larabie

I build with arbitrary dimensions, then scale to max out the vertical dimensions so if fits in 1200. That's 1000 plus the line gap. It lacks finesse, but maximizes cross platform/app/browser compatibility.

UPM 1000. The lowest accent, usually ogonek or comma-accent is my lowest point and the top of the Å is my high point. I scale the font so the difference between those points is 1200 or slightly less. My settings are based on the highest and lowest point measurements. hhea Ascender=highest point. hhea Descender=lowest point. linegap=0. TypoAscender = highest point minus 200. TypoDescender = lowest point. TypoLineGap = 200. WinAscent = highest point. WinDescent = lowest point

This technique may not adhere to specs, but nothing gets cut off and it looks the same across platforms. Maybe not the same but more "the same" than using "proper" settings. I'll go in an finesse the numbers in less conventional designs but that's my general technique.

Vietnamese stacked accents can go past the highest point. When you have wild swashes, or paint drips, you can go past the 1200 limit but you can't expect it to behave perfectly in all applications.

Bianca Berning

This thread is dealing with the same question but from a different angle. You might find it interesting.

http://typedrawers.com/discussion/452/1000-em-units/p1

I tend to agree with John Hudson: for a standard design one would want to aim for the default leading to not exceed around 125% of the body size. You can calculate backwards from there.

It essentially comes down to one's design, the intended usage of the font(s) and the target environments. Stacking diacritics (precomposed or on-the-fly) and some non-Latin scripts might leave you with crazy vertical dimensions that need more attention. Also, fonts for UI usage almost always need special treatment.

Max Phillips

For what it's worth, when I designed Spinoza, I made sure the tallest cap diacritic fit within the em.  I thought it was just plain wrong to make a typeface which, set solid, created collisions between descenders and cap diacritics, and I couldn't understand why everyone else seemed to think this was fine.

The result was a face that, viewed in type testers, looked 10% smaller than all its competitors.  I'm pretty sure this has hurt sales.

When I release the 2.0 version, it'll be 10% bigger on the em.  And the cap diacritics will stick up above the full body height, just like everyone else's.

Rainer Erich Scheichelbauer

I recently updated the Glyphs tutorial about vertical metrics and personally now use and suggest what I refer to as ‘The Webfont Strategy’. It ensures cross-browser consistency.

The cutting-off problem is related to WinAscent/WinDescent and hheaAscender/hheaDescender, not necessarily to the relation between UPM and bounding box height as suggested by the Twitter posting.

Deleted Account

How about with these?
Any thoughts on proper vertical metrics?

Thanks.

Dave Crossland

I suggest that your highest/lowest extrema points of the family should be scaled to fit within 120% of UPM. Its important that the vertical metrics of the family are used for all styles, so that when you mix styles in a line, the line-height doesn't alter (making that line break the rhythm of the other singe-style lines.

However, for David's example, I would recommend this only for each asc/descender family group, since those families are unlikely to be used together/mixed in single lines; rather, each is intended for use with different line-heights. 

Deleted Account

Yes, Dave, good point. The descender length here is only intended to be requerried at each line break. The issue to be tested, unless someone knows, is how many apps still loose track of pixels rendered outside of the em, leaving glyph bits behind during text editing. For static web text, I have not found any left bits.

I do get the feeling from test viewings, however, that the general web design and reading public's 21-year exposure to default line spacing is going to be as big an impediment to quality reading, as all the other non-defaults we've had to evangelize about real type since before the web. But there's no sense complaining when there's the suspicion of slowed reading somewhere. 

Michael Rafailyk

Ray Larabie said:

I build with arbitrary dimensions, then scale to max out the vertical dimensions so if fits in 1200. That's 1000 plus the line gap. It lacks finesse, but maximizes cross platform/app/browser compatibility.

UPM 1000. The lowest accent, usually ogonek or comma-accent is my lowest point and the top of the Å is my high point. I scale the font so the difference between those points is 1200 or slightly less. My settings are based on the highest and lowest point measurements. hhea Ascender=highest point. hhea Descender=lowest point. linegap=0. TypoAscender = highest point minus 200. TypoDescender = lowest point. TypoLineGap = 200. WinAscent = highest point. WinDescent = lowest point

This technique may not adhere to specs, but nothing gets cut off and it looks the same across platforms. Maybe not the same but more "the same" than using "proper" settings. I'll go in an finesse the numbers in less conventional designs but that's my general technique.

Vietnamese stacked accents can go past the highest point. When you have wild swashes, or paint drips, you can go past the 1200 limit but you can't expect it to behave perfectly in all applications.

Is it possible to set all this settings using a FontLab only, or this requires other tools? I found hhea Ascender/Descender/Line gap in Font info > Other values, but FontLab names the general values in its own way (human readable), and I'm trying to figure out what's where. Please correct if I'm wrong here:

Ascender – TypoAscender
Descender – TypoDescender
Line gap – TypoLineGap
Safe Top – WinAscent
Safe Bottom – WinDescent

Hrant Հրանդ Փափազեան Papazian

Making everything fit in the Em will: cause many people to not use your font because it looks ridiculously small; require typesetters to use larger point sizes with negative linespacing to avoid massively gappy lines, which is far worse than causing unwitting –and very rare– collisions, especially since negative linespacing will cause those collisions anyway. Basically, healthy linespacing requires some risk-taking. (Letterforms getting cut off is a solvable technical issue.)

Leaving some talus ("internal linespacing") is important to avoid collisions of basic things like g/y and f (when set flush) but rare things like cap accents should be allowed to drift above the Em.

Determining the talus comes first; around 5% is a good benchmark (and most of it should be allocated to the top). And flattening the cap accents to make them slightly ungainly (like one has to do even with the "g" anyway) helps reduce potential problems.

John Savard

Max Phillips said:

For what it's worth, when I designed Spinoza, I made sure the tallest cap diacritic fit within the em.  I thought it was just plain wrong to make a typeface which, set solid, created collisions between descenders and cap diacritics, and I couldn't understand why everyone else seemed to think this was fine.

The result was a face that, viewed in type testers, looked 10% smaller than all its competitors.  I'm pretty sure this has hurt sales.

When I release the 2.0 version, it'll be 10% bigger on the em.  And the cap diacritics will stick up above the full body height, just like everyone else's.

I agree that this is sad.

But one thing I remember is that when laser printers first started coming out, one of the first things I noticed was that "10 point Times Roman" coming out of them looked smaller than 10 point Times Roman in print.

So, to my way of thinking, there was a failure in making digital type 100% compatible with metal type.

It should have been possible to specify type so that the 10 point version can say "if you use these accents, you must also use one point leading". Or even to say you always have to use 10% leading - like Times Roman with long descenders (which they made that way so that it had the same x-height and cap height as the regular kind with short descenders).

Claudio Piccinini

Michael Rafailyk said:
Is it possible to set all this settings using a FontLab only, or this requires other tools? I found hhea Ascender/Descender/Line gap in Font info > Other values, but FontLab names the general values in its own way (human readable), and I'm trying to figure out what's where. Please correct if I'm wrong here:

Ascender – TypoAscender
Descender – TypoDescender
Line gap – TypoLineGap
Safe Top – WinAscent
Safe Bottom – WinDescent

The Line Gap value varies quite a lot across digital fonts. I don’t like when it is excessive, so I am making choices to make it about a 20% of UPM value max (about 205 for 1024, 410 for 2048). For example, Arial uses 307 and Cambria 353. Deja Vu Sans uses 410.

The WinAscent ("Safe Top") and WinDescent ("Safe Bottom") values should be the sum of the Ascender and Descender values plus the Line Gap value (i.e. if you have 1490 as the Ascender value, and a 410 Line Gap value, Safe Top will be 1900).

Michael Rafailyk

The WinAscent ("Safe Top") and WinDescent ("Safe Bottom") values should be the sum of the Ascender and Descender values plus the Line Gap value (i.e. if you have 1490 as the Ascender value, and a 410 Line Gap value, Safe Top will be 1900).

Thank you @Claudio Piccinini
Cross-platform vertical metrics is a hardest things for me now. Three different tables and so many different approaches. It could be clearer in a future and right now it's a challenge

I read this article https://glyphsapp.com/learn/vertical-metrics and at this moment choice Webfont strategy way with including important diacritics to the Ascender. Here what I have:

UPM = 1000
typoAscender = 910 (ÀÅ)
typoDescender = −210 (pĢ)
winAscent = 1080 (ẴẲ)
winDescent = typoDescender
Line gap = 120 (910+210−1000)

As result, the line spacing looks optimal and not too high. Important diacritics on bottom line do not touches the descenders on the top line. But Vietnamese diacritics touch descenders and I'm confused, what's better — a good line spacing for most languages or correct metrics for Vietnamese? In the second case my Line gap will be 290, but line spacing looks too high

John Hudson

Hrant,

Leaving some talus ("internal linespacing") 

From where do you get this term? I am familiar with two meanings of talus, from anatomy and geology, but have not come across this use before. I presume it shares the etymology of the other meanings in the Latin word for heel/ankle, so perhaps refers to a to bottom part of a piece of metal type, below the descender?

Hrant Հրանդ Փափազեան Papazian

I thought you were there when we discussed this on Typophile.  :-)  I remember there was some resistance to it then (if still now I'm sure, especially considering the source...) but once a heavyweight (either James Mosley or Robin Kinross, I believe) chimed in with support for the term things settled down.  :-)

It does come from metal type, where it's also called the "beard" but not consistently (plus that terms is a bit overloaded). There it's the slope from the face to the shoulder (which might sound like it should be called the "neck" :-) which typically only reaches the edges of the sort in all-caps fonts, so not the best validation... But in digital it's basically a nice tight term for referring to the combined space above the ascender line and below the descender line, to the edges of the Em. An extremely useful reference in terms of (virtually) eliminating collisions in flush setting versus how large the font appears on the body (although the x-height does do the latter to a greater extent).

Claudio Piccinini

Michael Rafailyk said:

Thank you @Claudio Piccinini
UPM = 1000
typoAscender = 910 (ÀÅ)
typoDescender = −210 (pĢ)
winAscent = 1080 (ẴẲ)
winDescent = typoDescender
Line gap = 120 (910+210−1000)

Windescent should be Descender+Linegap. I think that would be safer.

John Savard

Michael Rafailyk said:

But Vietnamese diacritics touch descenders and I'm confused, what's better — a good line spacing for most languages or correct metrics for Vietnamese? In the second case my Line gap will be 290, but line spacing looks too high

Why should you have to choose?

Surely the right answer is to have two versions of the font; one set up with a good line spacing for most languages, and another that properly supports Vietnamese.

Omit the Vietnamese-language support from the first one. Include both versions in the package, without doubling its price.

So when you need to use Vietnamese, you can simply use the other version of the font, which will increase the line spacing as needed.

It's just wrong to do things wrong. For Vietnamese or any other language. At least when doing things right is a choice that is available.

On the other hand, I can understand that including an extra version of each font in a package is confusing. Nobody seems to do this. In that case, if you ship the font with "a good spacing for most languages", but people using it to set Vietnamese, and who see descenders overlapping with accents can, even on the most primitive of word processing software (for example, WordPad on Windows) can specify additional line spacing, then that still allows the font to be used normally.

It's not as if all the accents that go outside the nominal range will get clipped by the renderer. Then the choice would be critically difficult.

If you included the extra line spacing for Vietnamese, making negative line spacing, which is more difficult to specify (many users wouldn't even suspect the option was available, even if it was), necessary to get acceptable results in any other language would obviously result in it recieving little use.

However, while this works for using the font for general typography, the issue of design templates was raised. That seems to imply that a special Vietnamese version of the font is necessary, to allow use with the Vietnamese language in combination with templates that prevent specifying additional line spacing. Possibly online forms might cause a similar problem too. I don't have the expertise to identify the seriousness of this issue.

Michael Rafailyk

@John Savard
It's food for thought and a real dilemma. Now I understand why the accents above the uppercase are smaller than those above lowercase (on some fonts), for save every available vertical unit.

Hrant Հրանդ Փափազեան Papazian

@Michael Rafailyk Which is also why the upper talus should be given the lion's share of the total talus.

Florian Pircher

How does mark to base and mark to mark factor into this? With mark to mark, combining marks can stack arbitrarily far above and below the base glyph. Using the highest/lowest metric of my precomposed glyphs feels arbitrary in the sense that which precomposed glyphs are blessed with a Unicode codepoint is somewhat arbitrary.

Is there a repository of commonly used typeforms for which no precomposed Unicode codepoints exist and which must be constructed using combining marks instead? Should such a repository even be consulted for vertical metrics, or are those solely based to the precomposed glyphs in the font?