Font with extremely tall ascenders/descenders in multiline text in Adobe applications

Michael Rafailyk

Hello, type drawers!
I'm currently working on a handwritten face with very long ascenders and descenders and I'm wondering what is the best way to set vertical metrics? I see two approaches here but not sure the first one is right:

1. Set x-height to normal and let ascenders/descenders go out of the box.
Pros: The font looks the same size comparing to the other fonts.
Cons: The line height (leading) in Adobe apps is 125% of the UPM by default, so descenders of a top line and ascenders of a bottom line intersect each other on multiline text. Of course, designer can set the leading and fix it, but it feels wrong.

2. Fit a whole height (from tallest to lowest point) to 100-125% of the UPM.
Pros: Multiline in Adobe applications looks right.
Cons: The font looks pretty small comparing to the others.

Has anyone come across a similar one, and how did you solve it?
Thanks.

Florian Pircher

I would try to match the apparent font size of other fonts. That way, if you later decide to release a companion family with more traditional ascenders/descenders, both fit next to each other in the same line of text.

John Hudson

We did production work on the version of Zapfino that ships with Mac OS, and the first release of that font was made—as requested by Apple—with the total overall height of the long extenders close to the overall metrics height of the font. Apple received a lot of negative feedback about the font ‘looking small’ relative to other fonts, so for a patch release of the OS Apple asked us to change the UPM value so that the font would scale larger. From this experience I can tell you that more people complain about fonts looking small than complain about the size of fonts changing dramatically between releases.

Thomas Phinney

The new Zapfino was 2.5x the size, wasn’t it? That was a huge change to make to a system font! It remains my favorite example of how digital font size is rather arbitrary.

Michael Rafailyk

@John Hudson Just a week ago, I checked Zapfino font metrics on my Mac, and now you tell a story behind it. It shed light, thanks!

André G. Isaak

Thomas Phinney said:

The new Zapfino was 2.5x the size, wasn’t it? That was a huge change to make to a system font! It remains my favorite example of how digital font size is rather arbitrary.

I'm not sure that I would refer to Zapfino as a 'system font'. It was distributed as part of MacOS, but AFAIK it wasn't a required font and was never actually used by the system.

Thomas Phinney

Sure, you could call it “an OS pre-installed font” or something like that. Bundled with the OS and normally pre-installed. 

Florian Pircher

André G. Isaak said:
it wasn't a required font and was never actually used by the system.

Once a font is shipped as part of an OS, software on that OS expects that font to be available. So while the core set of Apple provided apps might not have used Zapfino, third party apps might have. I cannot find any example of this for Zapfino specifically, but Palatino is also a system font by Zapf, used by the build-in reader mode in Safari, the Books app, or third party apps to show a registration card:

It would not surprise me if some other app uses Zapfino (or Optima) for its license certificate window. Removing these fonts in an OS update would break such apps (or at least render their license windows less celebratory).

A system font can also be used in documents. If a later OS release removed the font, a user would find their document with a fallback font. In that sense, any system provided front is a required font.

John Hudson

Microsoft makes a distinction between core fonts and system fonts. Core fonts are things like Times New Roman, Arial, Courier New, Segoe UI, and other fonts that are used, or have been used, as default fonts in a variety of situations in the operating system or other MS products. System fonts include the core fonts, but also any others that are bundled with the OS and hence subject to similar stability considerations.

Peter Constable

Windows has provided a lot of fonts "in-box", but the combined size of in-box fonts was starting to cause problems for some scenarios, such as low-cost devices with limited storage. For the first release of Windows 10, we were asked if the font footprint could be cut in half.

Obviously, breaking dependencies was going to be a problem. There were various things I suggested be done to mitigate risk of breaking dependencies, and some were done, but some related specifically to app dependencies (as opposed to content) were not.

What ended up being done was to refactor the way the "in-box" fonts are organized for distribution, with many fonts designed for scripts other than Latin/Greek/Cyrillic being moved into optional OS components. If users change their language settings to enable a language in that uses one of those other scripts, that will automatically trigger install of the corresponding optional font package. That doesn't mitigate 100% of risk of breaking dependencies, and there were some other follow-up changes made. Altogether, that seems to have worked out reasonably well.

At the same time, there was a separate exercise that we needed to do to define minimal  sets of fonts that would be guaranteed to be available in the different variants of the Windows OS (e.g., for Phone, Hololens, Xbox...). In particular, we defined a set that all "universal" Windows apps could take dependencies on. I'm not sure what current Windows thinking is about universal apps, though.

For the Windows desktop OS, you can see the list of fonts in all systems versus optional packs here.

André G. Isaak

Florian Pircher said:

André G. Isaak said:
it wasn't a required font and was never actually used by the system.

Once a font is shipped as part of an OS, software on that OS expects that font to be available.

I've always used the term 'system font' to mean 'required system font'  (for macOS, that used to be (many of) the ones in /Library/Fonts rather than System/Library/Fonts, though recently the font organization has changed)  but I can see why others mights not adopt that usage and I see your point.

However, I've always very strongly believed that if an application uses a font which isn't one of the required system fonts, it should always be able to gracefully fall back onto one of the core systems fonts. If it can't, the developer should really consider licensing the font for embedding in the application.

I've always been in the habit of removing as many system fonts as possible to reduce menu clutter, and I suspect that I'm probably not alone in this regard. It's annoying to have to scroll through a menu several screens long. Everything I don't regularly use (which is most of the fonts included with macOS) get moved into my FontExplorer X folder and are kept inactive until I actually need them for something.

The fact that the OS does allow you to remove most fonts means it isn't really wise for an application to assume they will be there just because they are bundled with the OS.