Slashdot Mirror
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.
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.)
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?
What you hear in the ear, preach from the rooftop Matthew 10.27b
Freetype's Truetype rasterizer is heinous.
Here, let me explain why.
Microsoft's rasterizer for truetype uses a % coverage estimation to determine if a given pixel should be colored or not. It bases this using a sub pixel calculation, since each pixel has a theoretical 16x16 grid. This gives 256 possible values for subpixel coverage. Microsoft's implementation assigns a granularity of 16 shades of grey, where Freetype, in their faulted "MORE IS BETTERER! DERP!" wisdom assign a full 256 shades of grey.
This is BAD. VERY BAD. BAD. No, More shades of grey does NOT make crisper lines. NO. BAD.
Here is why:
Truetype instructions arent always subpixel perfect in where they move a curve's control point. Dropping the granularity to 16 shades of grey allows a certain degree of "forgiveness" if a curve crosses part of a pixel that you want to keep a certain shade. Noteworthy instances are the dots above letter "i", or under an "!", or the whitespace inside a letter "A", especially at small sizes. This forgiveness is reciprocal; you dont need a full 100% coverage to have black, (in the case of dots above i and under !. This is important, because the glyph geometry may have a circle for the vectoral line of these features, which simply cant cover 100% of the pixel without crossing into the subpixel space of adjacent pixels. Unless the point is a perfect square, you cant really hint 100% coverage at tiny sizes with TTF hint programs. This means your choices with freetype are: A square point, a black point with fuzzy around it, or a fuzzy grey point. With MS's rendering method, you get: A black pixel, with no fuzz.), just like you dont need 0% coverage to have transparent in the whitespace of the letter A. Freetype's programmers seem quite bullheaded about this, and insist that 256 color shading is somehow an improvement, rather than undesirable. This manifests profoundly with truetype CJK type glyphs for kanji characters, italicized characters, and the like. Freetype will "blur" an edge you dont want blurred, simply because you cant keep the vector out of the subpixel space of that pixel. This is very undesirable, frustrating for font makers who want consistent viewing, and it needs to be changed.
Simply because you CAN get 256 shades does not mean it is appropriate, nor is it desirable.
(It really is one of the big reasons why fonts often look bad on linux systems. The patented status of the delta hint was only part of the problem, The rasterizer itself was a major problem as well. Hacking out the "feature" makes demonstrably cleaner looking fonts.)