Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Graphics Google Open Source Software

Google and Adobe Contribute Open Source Rasterizer to FreeType 77

Posted by timothy from the fonts-matter dept.
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.
This discussion has been archived. No new comments can be posted.

Google and Adobe Contribute Open Source Rasterizer to FreeType More

Google and Adobe Contribute Open Source Rasterizer to FreeType

Comments Filter:

  • I hope it is not... (Score:1)

    by Anonymous Coward
    patent encumbered. That is probably what will happen next: some troll will rise up and sue one of the three parties for infringement. With as backdrop: "we don't want to be competed against by a "free" (as in beer - they don't get the speech part) product.". Let's hope that won't happen.

    • Re: (Score:3, Interesting)

      by dosius ( 230542 )

      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: (Score:1)

        by Anonymous Coward
        No.

      • Re: (Score:1)

        by aliquis ( 678370 )

        To me patent trolling would be to sue products using patents you own but don't intend to use for a product.

        I don't know what the meaning is supposed to be but just suing because someone is breaching some patent you own and which are used in a product you make a living on I think is more ok.

        At least you're not patenting and suing just do sue.

      • 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

    • Re:I hope it is not... (Score:5, Informative)

      by Samantha Wright ( 1324923 ) on Saturday May 04, 2013 @03:35PM (#43630831) Homepage Journal
      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.

  • I wrote a CFF renderer in C# (Score:5, Interesting)

    by anss123 ( 985305 ) on Saturday May 04, 2013 @03:31PM (#43630813)
    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.)

    • What is hinting in this context?

      • Re: (Score:3)

        by wootest ( 694923 )

        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# (Score:4, Informative)

          by flargleblarg ( 685368 ) on Sunday May 05, 2013 @01:16AM (#43632983)
          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 wrote a CFF renderer in C# (Score:5, Informative)

        by anss123 ( 985305 ) on Saturday May 04, 2013 @03:45PM (#43630895)
        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).
      • You could describe it as "guided pixel snapping".

    • Is hinting much of a problem with retina and similar high resolution displays?

      • Re: (Score:3)

        by anss123 ( 985305 )
        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: (Score:2)

          by tlhIngan ( 30335 )

          My impression is that the TrueType guys obsessed about file size. Every table has its own structure, which is more compact than CFF's "one size fits all" approach.

          Well, when TrueType was conceived by Apple and Microsoft way back in the late 80s and early 90s (yes, Apple and Microsoft worked on something together despite both being blood enemies at that time), your average PC had perhaps around a megabyte of RAM and a handful of megabytes for a hard drive, if any (Macs could boot off of floppies). So disk sp

      • Yes. Not so much of an issue for, e.g., 12-point type, but one of the really nice things about retina displays is that you can display *really tiny* type, such as full-page documents scaled down to a tiny onscreen preview size, and still have perfectly legible (assuming your own vision is up to the task) 4-pt fonts. Not comfortable for extended reading, but useful for quickly seeing if you've got the right page/document.

      • Is hinting much of a problem with retina and similar high resolution displays?

        No, but cost is. Hinting lets a device designer choose a less expensive screen while retaining legibility.

    • I particularly liked how the CFF container format works. It almost parses itself

      This statement would imply that the specification of CFF is a metacompiler. Are you sure about that?

      • Re: (Score:3)

        by anss123 ( 985305 )
        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 stumb

        • That was just tongue-in-cheek, since the only thing that actually, literally parses itself that I'm aware of are self-hosting (metacircular?) metacompilers (just like the only thing that compiles itself are self-hosting compilers). :-)

          I'm pretty sure that a file format for that could be even simpler (some form of binary S-exprs comes to mind), but they were probably quite big on the "C" in the "CFF", since everyone uses fonts (and now you can even download them together with web pages) and it makes sense to

          • Re: (Score:2)

            by anss123 ( 985305 )

            but they were probably quite big on the "C" in the "CFF"

            My impression is that the TrueType guys obsessed about file size. Every table has its own structure, which is more compact than CFF's "one size fits all" approach.

            Type1 is the most complex container. I can easily make a T1 font that is valid but unparsable by common parsers. Not sure what Adobe was thinking there.

            (and now you can even download them together with web pages)

            The web fonts that are getting popular now are basically just TrueType with the tables ordered in a sensible sequence and some compression added (though you can embed a CFF font into a WOFF cont

            • My impression is that the TrueType guys obsessed about file size.

              It'd make sense: hard drives & RAM were still very limited in size/speed, so most programmers tried hard to conserve space AFAIK.

    • Sweet, I always wondered how hard it would be to make my own font renderer.
  • tug.org/tug2008/abstracts/tug08abstracts.pdf

    CC.

    • Re: (Score:1)

      by Anonymous Coward

      I have dabbled in type design and I can tell you straight away why Metafont didn't catch on: it's fucking hard to use for it's intended purpose. And if a programmer tells you that, you can well imagine what a professional graphics artist or type designer is going to think of Metafont.
      Result: there are (based on my vast experience of reading scientific articles and books typeset with Metafont) no beautiful Metafont typefaces. And that makes Metafont useless, because the only thing that we really care about i

  • People seem to obsess about fonts to the nth degree. Who really cares? The actual visible differences between fonts today and the bitmapped fonts of the 1984 mac classic are minimal and the amount of code generating todays fonts is way out of proportion with the actual improvements in their look. The law of diminishing returns doesn't even begin to describe it.

    • Re:Meh , fonts. Big deal. (Score:5, Informative)

      by anss123 ( 985305 ) on Saturday May 04, 2013 @04:17PM (#43631071)
      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: (Score:2)

        by jfengel ( 409917 )

        Ah, frak. Posting to undo the wrong moderation. Sorry 'bout that.

      • Re:Meh , fonts. Big deal. (Score:4, Informative)

        by Dan East ( 318230 ) on Saturday May 04, 2013 @05:56PM (#43631565) Journal

        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.

        • 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 windo

          • Re: (Score:1)

            by Anonymous Coward

            Until recently, almost all desktop monitors were 86 DPI/PPI.

            Nope. You had a few "standard resolutions", such as 1024x768, 1280x1024 and so on. And all of them came in various sizes, 13", 14", 15", 19", 21", 24" ...

            So no such thing as a "standard DPI". There never was. And there were even idiots who ran their display at a wrong resolution, such as 1024x768 stretched to fit a 1280x1024 display. A flat panel has only one true resolution, but idiots think they have "choice" in this matter because the windows driver offer choice. . .

          • Until recently, almost all desktop monitors were 86 DPI/PPI.

            That, sir, is a load of shit. Not only is it not true, but it's not even close to true. For example, all Mac monitors were once approximately 72 DPI.

    • lolwut.

    • I don't know about you, but I spend about 90% of my time on a computer reading text on some variety. It makes sense to spend time getting something we use so extensively right.

    • People seem to obsess about fonts to the nth degree. Who really cares? The actual visible differences between fonts today and the bitmapped fonts of the 1984 mac classic are minimal and the amount of code generating todays fonts is way out of proportion with the actual improvements in their look. The law of diminishing returns doesn't even begin to describe it.

      So you're suggesting that the technology to render bitmapped fonts on 512×342 monocrhome screen is appropriate for 2560x1440 24 bit color screens? We shouldn't even consider scalable vector fonts.

      I'm not a big fan of ad hominem arguements, but you sir are an idiot.

  • Great! Now fix TrueType! (Score:1, Interesting)

    by Anonymous Coward

    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

    • 50% grey is a pixel value near 192, not one near 128. A pixel walue near 128 is much darker.

      As far as I know, the engine doesn't handle this. It may even have some sort of hack to crudely compensate for the error, such as rendering things a bit more or less bold. Any such hack is unlikely to work with both white-on-black and black-on-white.

      I think the problem is even implicit in the API. You can't just render to bitmap, cache the bitmaps, then generate pixels with any color.

      Green on magenta tends to show th

      • Your operating system is gamma-aware. Unless you've run a color calibrator, you have no idea whether you're even capable of displaying the proper colors, or if you're set up to do that. The same is true of brightness. People who care drop the hundred bucks to buy a colorimeter. Once you profile your display, the operating system does the right thing, and the font renderer doesn't have to know anything.

        • Re: (Score:2)

          by r00t ( 33219 )

          Nope. There are two ways an OS can work, neither of which will do you any good. The simple way is that the OS just assumes your display hardware uses the sRGB gamma curve. Since the OS also assumes that all apps follow this curve, the OS does nothing. The complicated way is that you measure your hardware so that the OS can convert from sRGB to not-perfectly-sRGB that you have measured. In the complicated case, an app might supply a value of 127,127,127 and the OS turns it into 127,128,126 before handing it

    • Re:Great! Now fix TrueType! (Score:4, Interesting)

      by Psychotria ( 953670 ) on Saturday May 04, 2013 @09:13PM (#43632285)

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

      • Re: (Score:2)

        by caseih ( 160668 )

        To each his own. To me the infinality patches make the fonts look bad at small point sizes. The shapes get distorted. On my system I set the fonts to use the default FreeType subpixel anti-aliasing, and turn hinting completely off. This makes the fonts a bit blurrier at small resolutions, but the shape is so much better. I used to dislike the OS X way of doing fonts without any hinting, but now I quite like it. It's soft, easy on the eyes, still readable, and true to the font designer's design for sh

    • The actual reason for this happening is that Microsoft's renderer heavily clamps the font's outline to be on pixel boundaries. The point at the top of an "i" literally becomes a square, nothing to do with having fewer shades available.

      They actually changed this in Vista, with DirectWrite adding support for sub-pixel rendering (basically, removing the clamping). Many people reacted badly to it because it made things look a bit less sharp in the same way you dislike FreeType, and so very few apps actually tur

      • I happen to like the way FreeType does this (and Apple and Microsoft's new rendering in Vista (I forgot the name)). Although Microsoft's clamping to pixels avoids things getting fuzzy and hard to read, it also tends to make things look different from how they were supposed to look. Also (I suspect in combination with some kind of hinting), on Microsoft's old rendering, all fonts tend to look the same at small sizes.

        FreeType fonts used to be blurry to the point that they would be hard to read. I haven't had

      • Re: (Score:2)

        by yuhong ( 1378501 )

        Vista did not introduce DirectWrite. Win7 did and they backported it to Vista in a platform update.

    • Oh god please no. Windows' text rendering looks terrible.

  • While I applaud anything this complex being made open source, I'm wondering it it's a few years too late.

    We are on the cusp of an era of high pixel density ("retina") displays. Will we still need to worry about more complex rendering of fonts (ie: hints for small sizes), or just render at whatever point size to screen and be happy that the resolution is high enough to make whatever we display readable?

    • We are on the cusp of an era of high pixel density ("retina") displays. Will we still need to worry about more complex rendering of fonts (ie: hints for small sizes)

      Yes, we will. Non-"retina" displays (and I do hope we'll continue to put that particular buzzwords in quotes for a while yet) aren't about to obsolesce* overnight.

      *shame on Firefox for not knowing that word (or "Firefox") - it's perfectly cromulent.

    • Re: (Score:2)

      by Longjmp ( 632577 )

      ... or just render at whatever point size to screen and be happy that the resolution is high enough to make whatever we display readable?

      The problem with that is, if you have one display of a certain physical size, a display with double the resolution of the same size can make the text unreadable, because it's only half as big.

      What I'd be waiting for is a resolution-independent rendering system, but that means the displays would have to report their physical size, and the OS needs to be designed to take account of that.
      Apple's retina display (and rendering engine) is just a hack to simulate that (*), kind of simulating 4 pixels as one (o

      • 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 scre

  • More Adobe Viral Distribution Software (Score:1)

    by Anonymous Coward

    Is this yet again more buggy crap from Adobe, the company that specializes in the dissemination and propagation of computer virii through their shoddy code?

  • I keep seeing references to 'cff files'. Does this mean that this engine requires fonts to be in a new file format? Will we need someone to create all new fonts using this format?

Slashdot Top Deals

The use of money is all the advantage there is to having money. -- B. Franklin

Close