Google and Adobe Contribute Open Source Rasterizer to FreeType

alancronin writes with this excerpt from a PC World article: "Users of Android, Chrome OS, Linux, and iOS devices may not realize it, but FreeType open source software is used to render fonts on more than a billion such devices. Not only that, but the FreeType project this week got a significant update from none other than Adobe and Google. Specifically, Google and Adobe on Wednesday released into beta the Adobe CFF engine, an advanced Compact Font Format (CFF) rasterizer that 'paves the way for FreeType-based platforms to provide users with richer and more beautiful reading experiences,' as Google put it in an online announcement on the Google Open Source Blog. The new rasterizer is now included in FreeType version 2.4.12. Though it's currently off by default, the technology is 'vastly superior' to the old CFF engine and will replace it in the next FreeType release, the project says." The article features examples of how the new engine improves font rendering; for more explanation of the CFF, see this blog post from Adobe.

Comments

I wrote a CFF renderer in C#

[anss123]

The big headache with rendering CFF is the hinting. I just ignored the hints, which gave okay result with 12+ font sizes. But without proper hinting small font sizes quickly become unclear.

CFF is very similar to Type1 fonts, so presumably this will also result in better looking Type1 fonts. Basically CFF is a compact way of storing Type1 fonts. I particularly liked how the CFF container format works. It almost parses itself, type1 fonts take more effort to parse, and true type fonts take a lot more effort to parse (but non-hinted true type rendering is OTOH super easy.)

Re:I wrote a CFF renderer in C#

[Intrepid imaginaut]

What is hinting in this context?

Re:I wrote a CFF renderer in C#

[wootest]

Selectively varying the proportions of the glyphs or the spacing between them to produce crisper rasterized output.

Re:I wrote a CFF renderer in C#

[anss123]

In cff files there are commands that that describes the elements of a glyph. This is used to determine what is important when rendering fonts at small sizes. For instance you don't want the hole in the "A" character to disappear at smaller sizes.

True type files have small programs that you execute when rendering at small sizes that moves the points that makes up the glyph. CFF and Type1 has commands like "stemv" that describes a vertical stem, and then it's up to the renderer to best figure out what to do.

Type3 fonts have no hinting, and is often thought of as ugly for that reason, but with sufficient DPI they are just as good looking as any other type of font. They are a bit more annoying to render than Type 1 fonts, as they can contain color and even pattern fills, but AFAIK is not used much. My renderer can handle them too, except if they contain transparencies (AFAIK none do).

Re:I wrote a CFF renderer in C#

[anss123]

Shouldn't be. Hinting is really just a hack to make fonts look good when you only have a handful of pixels to draw with.

However asian true type fonts often abuse the hinting engine. I.e if you render them unhinted they don't render fully (True type hints are Turing complete programs, with all the ills that bring).

Re:I wrote a CFF renderer in C#

[anss123]

It's a very simple format. Just define a couple of structs, and implement a few commands, and it spits out the relevant font data in a nice "dictionary" like struct. Compare that with Type 1, where you need to write either a fuzzy parser or (what I did) a post script interpreter. TrueType is even worse, needing numerous parsers as each table is in its own unique format.

So no metacompiling, but a pleasant surprise after having struggled through the other two and done in a tenth of the time. The only stumbling block for parsing CFF is encryption (the charstrings are encrypted in a lame attempt to stop people from writing their own renderers), but the documentation now contains all the info you need to handle that.

Re:I wrote a CFF renderer in C#

[flargleblarg]

Well, no. Hints are metadata embedded in the font file which provide hints/clues to the rasterizer. The rasterizer then uses the hints to improve its own selective varying of the proportions. You can do selectively varying of proportions without hints. The hints just improve the process.

Finally, hinting is not the process of varying proportions. It's not even remotely that. Hinting is the process of adding hints to a font. A font designer takes a typeface and hints the font manually. Note that there are algorithms to assist with hint generation... hinting the hinting, if you will.

Re:I hope it is not...

[dosius]

I thought most of the important patents would be held by either Apple or Adobe...

Well, Apple could troll, but wouldn't that ruin whatever deal they have in place with Adobe re Quartz?

Re:I hope it is not...

[Samantha Wright]

Adobe and Microsoft (and maybe Apple?) collectively own just about every font patent imaginable. In the late 80s, Adobe's PostScript licencing was sufficiently heinous that MS and Apple teamed up to circumvent it; that's how TrueType came to be.

Re:I hope it is not...

[anss123]

TrueType was introduces in 1991, or perhaps even earlier. TrueType is based on Apple's SFNT fonts, which is older and type1 is older still.

So shouldn't all patents have run out by now?

Re:Meh , fonts. Big deal.

[anss123]

The problem with bitmapped fonts were never that they look bad, but they are difficult to scale to different font sizes. Say, if you got a bitmapped font with the sizes for 8pt and 12pt embedded, but you need them at 9.5pt, then you're stuck with using a image scaling algorithm.

TrueType/CFF are based on vectors, and saying that we don't need vector based fonts is a bit like saying that we don't need SVG since we got PNG.

Re:I hope it is not...

[MrHanky]

One of the most significant patents (owned by Apple) expired just a few years ago. I remember there was some code in XFree86 or Freetype or wherever that actually infringed on it, but the default build script commented it out. I also remember seeing a patch in one of the major Free Software GNU/Linux distros that happily circumvented it, resulting in quite decent font rendering. Of course, no one would suspect Debian of doing anything that would be good for desktops...

Re:Meh , fonts. Big deal.

[Dan East]

It's worse than that. You have 8pt and 12pt fonts embedded, but at what display DPI? The odds of being able to use the 8pt font bitmap at native 1:1 resolution and actually be the size an 8pt font should be is nearly zero.

Re:Great! Now fix TrueType!

[Psychotria]

I do believe that the patches from http://www.infinality.net/blog/infinality-freetype-patches/ are being slowly merged into freetype. In the meantime, use the infinality patches. They make a huge, huge difference.

Re:More Adobe Viral Distribution Software

[Psychotria]

The code was written by the freetype author, not Adobe or Google (i.e. they employed the freetype author for a little while to implement the changes they wanted into freetype).

86 DPI

[dutchwhizzman]

Until recently, almost all desktop monitors were 86 DPI/PPI. Any oddballs were professional graphic designer displays or a few extremely expensive laptops and of course the UNIX X displays on SGI, HP and SUN systems. Now we have retina displays, tablets, multiple-display setups and what not. Most operating systems now have some form of support for PPI independent rendering in place, but almost no applications support this yet. Try putting your laptop display next to an external display and getting the windows and fonts to be the same physical size and moving them from one screen to the other to see what I'm talking about. Embedding 8pt and 12pt fonts at 86DPI made a lot of sense when this standard was being devised. It wasn't until portable displays started becoming popular that 86DPI wasn't the standard anymore.

Re:Too late?

[TheRaven64]

Pretty much any vaguely modern API is resolution independent. Cocoa was even back when it was called OpenStep - everything is done in units of PostScript points, not pixels. The problem is that the display server has a fixed resolution. Before Xinerama, X11 was better at this, as each screen would report its own DPI and the toolkit could render windows at different sizes depending on which screen they were on. Unfortunately, the down side of this was that it didn't support windows spanning multiple screens. To do it properly, the toolkit has to be able to render different rectangles of each window at different resolutions. This isn't especially hard to do. With the OpenStep APIs, every view responds to a message that tells it to render the subset that overlaps a specific rectangle into the current graphics context, so you could just call that once for each rectangle and then composite the result. Or you could go for the really rough solution of having each overlapping window rendered 2 (or more) times, once for display and then cropping the result. The problem is that a lot of custom views do things like loading bitmap images depending on the resolution of the display, and these would end up looking ugly on the different screens.

Re:I hope it is not...

[bill_mcgonigle]

Well, Apple could troll, but wouldn't that ruin whatever deal they have in place with Adobe re Quartz?

Quartz/Display PDF was an end-run around Adobe in the first place. NeXT (err, Apple) wanted to keep using DisplayPostScript, but Adobe wanted NeXT-level licensing fees, not Apple-level licensing fees. At the same time, Adobe had already released PDF under a royalty-free license, and for Apple's purposes PDF was just compressed PostScript, so Apple changed their display server to DisplayPDF to avoid paying licensing fees. source: WWDC '98 presentation on the display server.