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.
Comments
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.
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.
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.