Vertical Metrics/UPM - (modular) linespacing

Vít Šmejkal

Hello,
I'm making a modular variable font and I'm struggling.
I cannot figure out how to correctly set the UPM and vertical metrics.
I have read many posts and manuals (Fontlab, Glyphs, Fontcreator), but I'm not any smarter.



I'm pretty sure I should set TypoAscender 1875, TypoDescender -425, TypoLineGap 0 and also check "prefer typo metrics", right?
(other values are not important in this case?)


But, does for example InDesign use exactly these values? (mainly the LineGap=0?).
I'm afraid it sets the linespacing to 120% of fontsize by default, so wouldn't that ruin my desired spacing?


And how about UPM?
- formerly the dogma was Ascender+Descender=UPM
- is it not needed anymore? Can this be arbitrary now?

What "value" would you suggest? Also please keep in mind that I will probably make a version of this font with denser linespacing (e.g. modulus of 2000 or so):

Of course, I want both fonts to display in apps in the same size (like above) - so I suppose they should have the same UPM (let say 2000) but different Ascender+Descender? 

Please help!

Colin M Ford

UPM

The usual values are 1000 and 2048. However, if you choose to use a value other than those, most modern programs should accommodate. If you're not concerned about the font being used in legacy systems than any number should be ok.

Vertical Metrics

You're right that the modern preference for vertical metrics is to set all "line gap" values to 0, see this guide by Google for Google Fonts. However, to my knowledge currently Adobe apps don't respect the "Prefer Typo Metrics" flag unless it is a variable font — though I might be mistaken. To get things to behave in Adobe apps, you might want to try the "Adobe Strategy" found on this Glyphs app doc.

Great looking font, by the way!

John Hudson

But, does for example InDesign use exactly these values?

InDesign does not use font metrics for linespacing. Linespacing in InDesign—and in general in design apps that come from a print-first background (unlike screen design tools like Figma)—is always explicit and set by the user, with the default being a percentage of the type size.

InDesign may use the Ascender value in a font to calculate the first-baseline distance from the top of a text frame, but that is also something that the user can override with a different option (e.g. cap height or leading), and individual users may set their own default preferences.

Which is to say that you really can’t anticipate how your font is going to appear in InDesign and a lot of other apps, because linespacing is not always handled the same way. Even in some apps that do use font metrics to determine linespacing, e.g. MS Word, the default linespacing might be 1.3× the font metrics and, again, can be overridden by users.

For your font, I suggest a method in which you try to keep all vertical metrics settings in sync, avoiding any linegap, and matching the UPM value of the font to the total height of the glyphs. That way, you can tell users of programs like InDesign to set the text solid, i.e. equal type size and leading.

So, e.g.

UPM = 2300

OS/2 sTypoAscender = 1875
OS/2 sTypoDescender = -425
OS/2 sTypoLineGap = 0

OS/2 usWinAscent = 1875
OS/2 usWinDescent = 425

hhea ascender = 1875
hhea descender = -425

That should provide the most consistent results across various platforms, and a simple method for achieving the desired result in environments that require the user to explicitly set or override default linespacing.

Vít Šmejkal

John: do I understand correctly:
If I set it exactly as you suggest - would be the user in Adobe apps forced to use the same value in Font size and Leading boxes? (i believe so)


As the the default value is for leading in Adobe Apps is 120% of UPM, there may be a second option to set the UPM to 83.33% of 2300, i.e. UPM 1917.
(but this will work "only" if the default leading is "exactly" 120% then...)

Whoud this UPM change affect other apps too? (those who respet typo-values)
I believe not the leading but actual on-screen size: it will apper bigger - right?



The second issue - denser variant:

Let suppose the second one has the line-height of 2000 instead od 2300.
If I want them to have a same on-screen size (like on preview) they both should have the same UPM (but different Ascenders/Descenders), correct?

This should work in "typo-value" sensitive apps, but it would cause the line-leading "mess" in Adobe I'm affaraid. (am I right?)

And when I set the UPM of 2300/2000 respectively, it should be also fine (even in Adobe), but the actual/relative fontsize will differ, I suppose:

Is that right?

John Hudson

If I set it exactly as you suggest - would be the user in Adobe apps forced to use the same value in Font size and Leading boxes? 

Correct.

As the the default value is for leading in Adobe Apps is 120% of UPM, there may be a second option to set the UPM to 83.33% of 2300, i.e. UPM 1917.
(but this will work "only" if the default leading is "exactly" 120% then...)

You could, but since that setting is only a default (the first thing I do when setting up my own InDesign preferences is to change that to 125%), I think it is easier for a project like yours to specify solid-set, i.e. no linespacing.

The denser variant design is problematic, though, if following my suggestion, because as you observe changing the UPM while also keeping the solid-set concept will mean different relative scaling.

There isn’t a very clean way to handle the two variants. One approach would be to use my solid-set concept for the denser variant, and then use something like the 120% linespacing concept for the looser variant. But obviously you would need to communicate this to users in some way.

Vít Šmejkal

Thank you both for your insights!

I think I will go as you suggest, John.

This font is going to be primarily variable (with some static instances alongside)
Therefore I'm mainly concerned about "variable" enviroments: Adobe apps and Web (browsers)

So one more question:
Should these settings work smoothly in web browsers to?
I guess all(?) browsers use "typo metrics" and therefore the leading should be OK on web too?

Scott-Martin Kosofsky

I have nothing of value to add to the issue at hand, but I would like to say that, if I were designing a book on astrophysics, I would surely consider this font for the titling—very cool!

Vít Šmejkal

Scott-Martin Kosofsky said:

I have nothing of value to add to the issue at hand, but I would like to say that, if I were designing a book on astrophysics, I would surely consider this font for the titling—very cool!

Thanks 

Florian Pircher

It could be interesting to add a design variation axis that adds additional lines so that the font can be used with different amounts of leading. E.g., a Stripe Extended axis where at 0 all additional lines below the descender are zero-width, between 9.99 and 10 the first line extends to the full glyph width, between 19.99 and 20 the next line below extends to the full width, and so on.

John Hudson

As far as I know, modern versions of most browsers should support the fsSelection use-typo-metrics flag. Of course, older versions of some browsers persist in use.

Vít Šmejkal

Florian Pircher said:

It could be interesting to add a design variation axis that adds additional lines so that the font can be used with different amounts of leading. E.g., a Stripe Extended axis where at 0 all additional lines below the descender are zero-width, between 9.99 and 10 the first line extends to the full glyph width, between 19.99 and 20 the next line below extends to the full width, and so on.

Interesting idea - I will consider it.

Or perhaps, the user can just change the leading to the exact fraction of the modulus (46 horizontal lines), e.g. the leading set to 21/23 (42/46) of the fontsize shoud reduce 4 lines, as they will exactly overlap.
However I'm not sure whether those overlaped lines wouldn't render a bit bolder?

Nevertheless, unfortunately this "fractional fiddling" would be probably necessary even if there is this special design axis.

Matthew Smith

I apologize that this isn’t on the topic of line height/vertical metrics, but does your font have an axis where all of the lines are completely horizontal and the letters are “invisible?”

In my head you could easily interpolate between the two axes which could provide for a really cool animated effect. However, the reality of that interpolation may not be as simple as I am imagining.

Just an idea!

Vít Šmejkal

Yes, exactly - that's what I did   

Actually the "fully horizontal" master will be the 50% intermediate - so the full iterpolation would go from Emboss to Deboss.