Hi,
I was just doing some research on what font formats are provided with each type of licence today (desktop, web, app). It would be great to simplify things for users and send just the font format that is needed. It seems quite clear that otf and woff2 make the work for desktop and web (with some exceptions) but I still have doubts about the app license. App developers I’ve worked with asked me for ttf files some time ago but, if I am not wrong, otf files make the work as well. What font format do you provide users that buy app licences? Only ttf? Only otf? Both?
Looking forward to hearing your thoughts and comments on this. Thanks!
0
Comments
A year ago I would have thought OTF did fine, but apparently our customers say otherwise. Having said that, I’d be happy to know more about what the real-world requirements are for app developers these days.
There are apps that actually use the web framework for user interfaces (e.g. the so-called Electron apps where they bundle a full copy of a Chrome-derived browser, and all user interface is done with HTML). For them, actually, WOFF2 would be the best option because it just makes the fonts smaller, and there is no difference for the app.
And finally, there are apps that for some part use a custom font engine. For example, an app may have a PDF creation module that generates some sort of reports (for example an invoice management app), or perhaps a PDF previewing module. Or these apps do something like displaying type in a 3D game or with video.
Then it’s crucial to now what the custom font engine likes. There are quite a few custom font engines that strongly prefer a particular format, often it is TTF. OTF is often avoided in these cases because the custom font engines from 10+ years ago had troubles with properly implementing all of OTF, for various technical reasons.
There are more independently-made TTF renderers in the world than there are independently-made OTF renderers. One of the reasons in the past was that the hinting behavior of TTF used to be fully specified in the format specification, while parts of the hinting behavior in OTF was only known to Adobe.
This has changed in two ways — on one hand Adobe has contributed their coffee to FreeType, on the other hand Microsoft has made proprietary changes to TTF hinting in their ClearType. So it’s largely even now, but many apps use font engines made many years ago when this wasn’t true.
It’s true that there are now more solutions, like FreeType+HarfBuzz, which are opensource and gracefully deal with both TTF and OTF (and also variability and complex-script layout) — but these solutions are tied to a particular programming language (primarily C/C++). There are ways to “bridge” them to other languages, but some app developers may prefer to use the simpler, native solutions, which, as I said, often are TTF-only.
There’s no clear answer, in Unity, what we use and the most common tool for video games, both ttf and otf are compatible. If we go to Swift native programming language for iOS the same thing happens, both formats are compatible and the same for Android. In other words, in the most common tools and languages, those used by practically everyone, there is no difference.
This may be true if the game really bundles static assets with pre-rendered text.
However, if the game generates some text dynamically, be it from user input (like entering the gamer’s nickname, in-game chat) or even character dialogue or some descriptions if they’re generated live, then it is bundling a font.
Even if the game creates some sort of “sprite collection” (bitmap or otherwise), and composes the text dynamically from it, that thing would be considered a font derived from the original font, and this should also be considered bundling the font.
The typographic rendition of a given text is the output of the software program, or the result of using the tool / the apparatus. As such, it’s typically not subject to the original font’s license.
But a different tool / apparatus that mimics the function and the result of the digital font, that is can be used to generate typographic renditions of different texts, and those renditions have the same appearance as what the original font produces — that would be considered derivative work of the font, even if it’s expressed in a format different from the original. The process of creating this derivate work should be considered “conversion”, and that thing should be subject to the original font’s license.
(I’m not a lawyer, and all of my above remarks are not to be considered legal advice.)
The distinction between web apps and mobile / desktop apps is blurry.
The distinction between mobile apps and desktop apps is also blurry:
If you're contacted by a software developer and they think they need to install the fonts explain that they can call the font from a library without installing it. I sent an indie developer this link and they found it helpful. Does anyone know if its the same kind of deal on a Mac?
- https://developer.apple.com/documentation/uikit/text_display_and_fonts/adding_a_custom_font_to_your_app
- https://developer.apple.com/documentation/swiftui/applying-custom-fonts-to-text
- https://doc.qt.io/qt-5/qfontdatabase.html
I could say the same about using WOFF as an embedded app font, although I don’t really remember contemplating that specifically when WOFF was getting created. The real point is that the format was (among other purposes) meant to lessen the risk of posting a commercial font file on the open web — i.e. people who download it can’t use it for other things.