The Benefits Of OpenType/CFF Over TrueType
OpenType/CFF (.otf file extension) and TrueType (.ttf file extension*) are the two modern font formats available for desktop usage today. Despite being distinct formats, OT/CFF and TT fonts actually have a lot in common. They are distinguished primarily by their different outline formats and the contrasting approaches employed to rasterize those outlines.
The glyph outlines in OT/CFF fonts are made of cubic Bézier paths whereas in TT fonts they’re made of quadratic Béziers.
Two similar paths. Cubic Bézier (left) and quadratic Bézier (right).
I would say that the majority of type designers prefers to use cubic Béziers because they’re easier to manipulate and are able to represent a wide variety of curves with fewer points than quadratic Béziers. Many of the designs available in TrueType format may actually have started their life as PostScript outlines — type lingo for cubic Béziers — and were converted at some point in the process. This conversion, if not done properly, may result in distortions to the outlines.
While the qualities mentioned above may give a bit of an edge to OpenType/CFF, I’m certain that they won’t persuade everyone. But what if I tell you that on average OT/CFF font files are 20% to 50% smaller than comparable TrueType fonts? Does that grab your attention? Sure, you can still think it’s not that important. After all, modern hard drives are big enough and font files are actually some of the smallest assets in a project, especially when compared to print-resolution images, video files or even the artwork files themselves.
Nevertheless, you’ll have to agree that smaller font files are surely desired for fonts used in web pages, fonts used in resource-limited devices, or a combination of both: fonts delivered to and displayed by portable devices. And if you think about CJK (Chinese, Japanese, Korean) fonts which contain tens of thousands of glyphs and files ranging around 5–10 MB, size considerations become quickly obvious.
So what makes OT/CFF fonts smaller? One of the reasons lies in the compact way in which the outlines are stored. For those of you unfamiliar with the term, CFF stands for Compact Font Format (PDF file) and the compactness of a CFF font is in part achieved via a technique called subroutinization, which is performed when the font file is generated. Subroutinization is a process that surveys all the glyphs in the font looking for path segments that are identical and thus can be replaced by a shared routine/command. The more regularized the glyphs are, the more compact the font will be. The TrueType format also has a mechanism that allows turning a given glyph into a component which can then be reused by other glyphs — think of the glyph representing the letter A being reused in the glyph for the letter Á (A with acute accent). This method will also decrease the font file size, but the reduction is not as significative as with subroutinization.
The other reason why OT/CFF fonts are smaller has to do with the much reduced hinting information contained in them (compared to TrueType fonts) — which brings me to the second benefit. Hints are parameters and/or instructions that are put in fonts for the purpose of helping the rasterizer — the program that converts the vector outlines into groups of pixels or dots — make better decisions about how to fit a scalable outline onto a fixed grid.
When it comes to hinting, the two font formats have opposite approaches. In broad terms, in TrueType the hinting “intelligence” resides in each font, whereas in OpenType/CFF the intelligence is mainly in the rasterizer. This means that TT fonts can contain very detailed instructions that specify, down to individual pixels, the way each glyph should render; the rasterizer thus becomes a “dumb” interpreter that simply processes those orders. On the other hand, the hints in OT/CFF fonts only provide general information about the font and about the main features of each glyph; it’s then up to the rasterizer to render everything the best way it can. Obviously, each approach has it’s pros and cons. While in TrueType one can have great control over the rasterization, that comes at a very high price; adding good hints to a TT font is a laborious task that requires a great amount of expertise and many years of experience. In contrast, hinting a OT/CFF font takes less that one tenth of the time and requires only a fraction of the knowledge. Having the intelligence in the rasterizer also has the advantage that when it gets improved, all the fonts benefit from it, without the need of being updated.
It is true that the type of hinting allowed by the OT/CFF format provides only limited control which may not be suitable for some kinds of applications and devices. But if you consider that the pixel-density of a growing number of screens is on the rise, and that some environments such as Mac OS X and iOS disregard font hints — TT and OT/CFF alike — investing significantly in hinting may turn out to be a not-so-great bet.
In sum, the two main benefits OpenType/CFF fonts have over TrueType fonts are 1) their smaller file size, and that 2) they require far less hinting information in order to render well in environments that allow some form of anti-aliasing.
Considering these advantages and with all other things being equal, some may ask: why isn’t the OT/CFF format as popular, as widespread and as well-supported as TrueType, even in environments that would benefit from them? I can point out several reasons. For one, the TrueType format has been around for much longer than OpenType; it debuted in the late 1980s while the first OT/CFF fonts were released roughly ten years later. The second reason is perhaps related to legacy display modes: on an aliased environment, TrueType is able to deliver a superior solution — due to to its hints and ability to leverage handmade bitmaps — that OpenType/CFF would have a hard time matching. And lastly, historical reasons: despite supporting OT/CFF, the two major desktop platforms, Windows and Mac OS, are largely invested in TrueType and when it comes to testing fonts in their apps and OS, OpenType/CFF hardly registers on the radar.
The rise of DirectWrite will definitely contribute to making OT/CFF fonts first-class citizens on Windows. And given Adobe’s commitment to open-source, I’m hopeful that support for OpenType/CFF on emerging platforms such as Android will not face the shortcomings of the past.
* Although they can actually use an .otf extension as well.
19 Responses
Comments are closed.
Font Wars II – Adobe Strikes Back!
Happy Holidays, Si.
Seasons greetings!
May the fonts be with you… always 🙂
At the end of the day though, wouldn’t you agree that the problems with CFF outweigh the benefits? Aren’t Adobe’s webfont offerings all TrueType? Or perhaps this a pre-emptive argument for some day in the future when you expect hinting to be a non-issue?
The problems are not with the format itself but with poor support for it in some places.
Yes they are, and let me tell you, they are a pain in the bottom to make.
Perhaps. We surely have discussed it internally.
Right, perhaps I should re-phrase: … wouldn’t you agree that the problems with using CFF outweigh the benefits?
As of today and if you want to cater for the widest on-line audience? Yes definitely.
I’m hopeful that things will be more balanced in the future, but I have no illusions that it will take time and many coordinated steps.
Question: why do Adobe products use strong, crisp or smooth renderings? Why not offer designers a chance to preview fonts as they will actually be rendered on screen within Mac or Windows environments?
In order to provide a cross-platform solution, Adobe apps have to use an Adobe rasterizer. Strong/crisp/smooth are the options that rasterizer has. Giving the users an option named “platform” sounds like a good idea. But don’t expect to be using Photoshop on the Mac and be able to preview how the text renders on Windows. That’s just not possible.
Thanks for this summary.
One indicator for OT/CFF as a poor 2nd class Windows citizen is the fact that only OT/TTF can be embedded into certain MS Office application’s documents. Do you think that will change?
I don’t know. But I don’t see why not since OpenType/CFF is a standards-compliant format just like OpenType/TT is. But you’ll need to ask Microsoft.
Punching itself in the nose, perhaps:) And if there is anything else MS, Adobe or the W3C can do to help with font, text, or typographic disintegration, I will be sure to let you al know 🙂
Great! It’s good to have you on our side.
“Adobe’s commitment to open-source, I’m hopeful that support for OpenType/CFF on emerging platforms such as Android will not face the shortcomings of the past.”
This is great to hear – and I hope Adobe’s commitment to open-source will extend to the AFDK eventually 🙂
Yeah, we may do it eventually. For now, it’s just free for everyone to use it http://www.adobe.com/devnet/opentype/afdko/
Open type’s main advantage is only alluded to here with Asian languages. The big advantage is you can fit a zillion accents for different languages, ligatures and alternate letters, a huge plus. Slow adoption, however? If your company has spent thousands of dollars on fonts, you really don’t feel like re-buying them again for something that comes up so seldom. For example, to get a slanted lower case “e” in Avant Garde, once a common request with photolettering, is it worth it to buy the font — at least not until someone asks for it.
When it comes to hinting, in practice, there is little “intelligence” in most TrueType fonts, either. TT fonts often use their detailed instructions for glorified “pixel-popping” instead of encoding constraint behavior—with commensurate font size increases.
Beat knows what he’s writing about. To put this into a broader context, one of the primary functional differences between CFF and TrueType is the way each strikes a balance in the “division of labor” between what’s handled by the font and what’s handled by the rasterizer. Both formats share responsibilities between the font and the rasterizer, but CFF does more in the rasterizer while TrueType does more in the font. This distinction is becoming less meaningful in modern antialiased environments, which use fewer of the rasterization instructions in either format.
If I am on Windows XP and print to a GDI printer, how are CFF fonts rendered? Are they converted into bitmaps or sent as TT outlines? I am pretty sure that the GDI renderer on the printer understands TT.
What if it is a PCL printer? These are common situations.