Google and Adobe Contribute Open Source Rasterizer to FreeType

← Back to Stories (view on slashdot.org)

Google and Adobe Contribute Open Source Rasterizer to FreeType

Posted by timothy on Saturday May 4, 2013 @07:17AM 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.

77 comments

Min score:

Reason:

Sort:

I hope it is not... by Anonymous Coward · 2013-05-04 07:24 · Score: 1

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.
1. Re:I hope it is not... by dosius · 2013-05-04 07:32 · Score: 3, Interesting
  
  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
2. Re:I hope it is not... by Samantha+Wright · 2013-05-04 07:35 · Score: 5, Informative
  
  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.
  
  --
  Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
3. Re:I hope it is not... by Anonymous Coward · 2013-05-04 07:54 · Score: 1
  
  No.
4. Re:I hope it is not... by anss123 · 2013-05-04 07:56 · Score: 3
  
  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?
5. Re:I hope it is not... by Samantha+Wright · 2013-05-04 08:17 · Score: 1
  
  Well, there are still a lot features like hinting and sub-pixel smoothing that were added on later.
  
  --
  Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
6. Re:I hope it is not... by aliquis · 2013-05-04 09:19 · Score: 1
  
  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.
7. Re:I hope it is not... by MrHanky · 2013-05-04 09:23 · Score: 3, Informative
  
  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...
8. Re:I hope it is not... by bill_mcgonigle · 2013-05-05 01:41 · Score: 2
  
  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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
I wrote a CFF renderer in C# by anss123 · 2013-05-04 07:31 · Score: 4, Interesting

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.)
1. Re:I wrote a CFF renderer in C# by Intrepid+imaginaut · 2013-05-04 07:32 · Score: 2
  
  What is hinting in this context?
2. Re:I wrote a CFF renderer in C# by wootest · 2013-05-04 07:44 · Score: 2
  
  Selectively varying the proportions of the glyphs or the spacing between them to produce crisper rasterized output.
3. Re:I wrote a CFF renderer in C# by anss123 · 2013-05-04 07:45 · Score: 4, Informative
  
  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).
4. Re:I wrote a CFF renderer in C# by Anonymous Coward · 2013-05-04 07:57 · Score: 0
  
  You're either trying to be funny or a blathering idiot. Could you give us a hint?
5. Re:I wrote a CFF renderer in C# by jonbryce · 2013-05-04 07:58 · Score: 1
  
  Is hinting much of a problem with retina and similar high resolution displays?
6. Re:I wrote a CFF renderer in C# by gigaherz · 2013-05-04 08:02 · Score: 1
  
  You could describe it as "guided pixel snapping".
7. Re:I wrote a CFF renderer in C# by anss123 · 2013-05-04 08:10 · Score: 2
  
  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).
8. Re:I wrote a CFF renderer in C# by flimflammer · 2013-05-04 08:17 · Score: 0
  
  The wink should have been obvious that he was kidding.
9. Re:I wrote a CFF renderer in C# by Longjmp · 2013-05-04 08:36 · Score: 0
  
  No worries, you simply have to accept the fact that kiddies these days don't get it unless there's at least a LOL, lololol, or Omg LMAO in the sentence. ;-)
  
  --
  There are fewer illiterates than people who can't read.
10. Re:I wrote a CFF renderer in C# by K.+S.+Kyosuke · 2013-05-04 09:07 · Score: 1
  
  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?
  
  --
  Ezekiel 23:20
11. Re:I wrote a CFF renderer in C# by anss123 · 2013-05-04 09:24 · Score: 2
  
  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.
12. Re:I wrote a CFF renderer in C# by phantomfive · 2013-05-04 09:43 · Score: 1
  
  Sweet, I always wondered how hard it would be to make my own font renderer.
  
  --
  "First they came for the slanderers and i said nothing."
13. Re:I wrote a CFF renderer in C# by K.+S.+Kyosuke · 2013-05-04 09:43 · Score: 1
  
  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 make it a wee bit smaller at the cost of complicating stuff quite a bit.
  
  --
  Ezekiel 23:20
14. Re:I wrote a CFF renderer in C# by anss123 · 2013-05-04 10:05 · Score: 1
  
  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 container, but I've yet to encounter such a font... I don't know how to handle subroutines when a CFF font is embedded in a TrueType container, so I'm a bit interested in getting my hand on such a font so that I can add support for it in my renderer.)
15. Re:I wrote a CFF renderer in C# by femtobyte · 2013-05-04 16:42 · Score: 1
  
  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.
16. Re:I wrote a CFF renderer in C# by flargleblarg · 2013-05-04 17:16 · Score: 4, Informative
  
  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.
17. Re:I wrote a CFF renderer in C# by TheSeatOfMyPants · 2013-05-04 17:22 · Score: 1
  
  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.
  
  --
  Now mostly at Usenet:comp.misc & SoylentNews.org (it's made of people!)
18. Re:I wrote a CFF renderer in C# by MysteriousPreacher · 2013-05-05 03:49 · Score: 1
  
  No worries, you simply have to accept the fact that kiddies these days don't get it unless there's at least a LOL, lololol, or Omg LMAO in the sentence. ;-)
  Indeed, old chap. In the future, anyone not employing at least one LOL variant every six words will be considered emotionally dead. Obituaries and formal declarations of war will be interesting.
  
  --
  -- Using the preview button since 2005
19. Re:I wrote a CFF renderer in C# by tlhIngan · 2013-05-06 03:31 · Score: 1
  
  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 space and memory consumption was VERY critical, because there wasn't a lot of it.
  Of course, we've also standardized on the TTF file format promoted by Microsoft on this (OS X uses TTFs, no more "suitcase" fonts).
  These days, memory is not so much of a constraint when even the crappiest of smartphones has 256MB and storage in the handful of gigabytes - that's more than enough.
Metafont by foobsr · 2013-05-04 07:35 · Score: 1

tug.org/tug2008/abstracts/tug08abstracts.pdf
CC.

--
TaijiQuan (Huang, 5 loosenings)
1. Re:Metafont by Anonymous Coward · 2013-05-05 01:04 · Score: 1
  
  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 in a type renderer (except apparently if you're a writer of scientific articles and books) is whether we get beautiful letters on screen or (to a smaller extent these days) on paper.
2. Re:Metafont by Anonymous Coward · 2013-05-05 02:51 · Score: 0
  
  Metafont has one less than stellar use that caught on... use by one of the two packages for generating Feynman diagrams, which does so via turning the diagram into a glyph. This has the lovely "feature" of now your diagram being stored somewhere in the TeX file hierarchy for all eternity, so you could come back a year later, accidentally name a new diagram that same as an old one, and you will get your old diagram stuck into your new document regardless of what diagram you described in the document.
Excellent news! by Anonymous Coward · 2013-05-04 07:36 · Score: 0

Can't wait for this to be rolled into a Linux distro. :)
Meh , fonts. Big deal. by Viol8 · 2013-05-04 08:09 · Score: 1

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.
1. Re:Meh , fonts. Big deal. by anss123 · 2013-05-04 08:17 · Score: 4, Informative
  
  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.
2. Re:Meh , fonts. Big deal. by Anonymous Coward · 2013-05-04 08:17 · Score: 0
  
  Because not everyone speaks with the same alphabet, and even when they do there are many issues with rendering them artistically that a 1984 Mac wasn't quite capable of pulling off.
3. Re:Meh , fonts. Big deal. by flimflammer · 2013-05-04 08:18 · Score: 1
  
  lolwut.
4. Re:Meh , fonts. Big deal. by jfengel · 2013-05-04 08:26 · Score: 1
  
  Ah, frak. Posting to undo the wrong moderation. Sorry 'bout that.
5. Re:Meh , fonts. Big deal. by Anonymous Coward · 2013-05-04 08:53 · Score: 0
  
  Who really cares?
  Those that appreciate reading an e-book typeset with Garamond instead of Comic Sans.
  Or those that like having a GUI that has text elements "designed properly" and not by a six year old child.
  Take your pick. Reading is important, so important is giving the reader the pleasure of a nice typography. I'd bet you'd go crazy reading a math book typeset in Comic Sans, or a History book in Comic Sans or any other kind of professional printed book.
  And no, I'm not a type designer. But I like reading nicely typeset books.
6. Re:Meh , fonts. Big deal. by lattyware · 2013-05-04 08:59 · Score: 1
  
  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.
  
  --
  -- Lattyware (www.lattyware.co.uk)
7. Re:Meh , fonts. Big deal. by H0p313ss · 2013-05-04 09:24 · Score: 1
  
  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.
  
  --
  XML is a known as a key material required to create SMD: Software of Mass Destruction
8. Re:Meh , fonts. Big deal. by Dan+East · 2013-05-04 09:56 · Score: 3, Informative
  
  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.
  
  --
  Better known as 318230.
9. Re:Meh , fonts. Big deal. by Anonymous Coward · 2013-05-04 11:54 · Score: 0
  
  > TrueType/CFF are based on vectors
  No, they are based on Bezier curves.
10. Re:Meh , fonts. Big deal. by Mprx · 2013-05-04 18:38 · Score: 1
  
  The most legible font is the font you're most familiar with. I used to take fonts very seriously, tweaking Fontconfig settings, etc. I now use default sans-serif for everything. I literally don't know what font it is, and it's just as legible as my customized setup. Despite all the jokes about Comic Sans I doubt it would take more than a week to get used to it.
Great! Now fix TrueType! by Anonymous Coward · 2013-05-04 09:03 · Score: 1, Interesting

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.)
1. Re:Great! Now fix TrueType! by Anonymous Coward · 2013-05-04 09:12 · Score: 0
  
  Are you sure Microsoft didn't PATENT the 16 shades of grey in the font rasterizer ?
  That would explain why the Freetype project had to use a different value.
2. Re:Great! Now fix TrueType! by Psychotria · 2013-05-04 13:13 · Score: 3, Interesting
  
  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.
3. Re:Great! Now fix TrueType! by PhrostyMcByte · 2013-05-04 13:24 · Score: 1
  
  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 turn this feature on.
4. Re:Great! Now fix TrueType! by inglorion_on_the_net · 2013-05-04 15:18 · Score: 1
  
  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 that problem for years (I think the autohinter fixed that). Of course, more pixels also help. Yay, higher-resolution displays!
  
  --
  Please correct me if I got my facts wrong.
5. Re:Great! Now fix TrueType! by caseih · 2013-05-04 16:54 · Score: 1
  
  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 shape at nearly any point size. I don't use any non-latin font, so I don't see the issues others have seen where the hinting code in a font is abused to display asian letters.
6. Re:Great! Now fix TrueType! by yuhong · 2013-05-04 17:04 · Score: 1
  
  Vista did not introduce DirectWrite. Win7 did and they backported it to Vista in a platform update.
7. Re:Great! Now fix TrueType! by VortexCortex · 2013-05-04 21:42 · Score: 1
  
  Are you sure Microsoft didn't PATENT the 16 shades of grey in the font rasterizer ?
  It's nearly impossible to be sure if they did or didn't, and if you try to find out, then you come to know you're infringing a patent, then 3x damages can be levied against you if they sue... IMO, I would go with a non power of two in order to reduce the likelihood that exact number of shades would be infringing. So, instead of 16, 32, or 64, perhaps 50 shades of grey would be a good compromise.
8. Re:Great! Now fix TrueType! by Vegemeister · 2013-05-05 00:54 · Score: 0
  
  Oh god please no. Windows' text rendering looks terrible.
9. Re:Great! Now fix TrueType! by Anonymous Coward · 2013-05-06 06:46 · Score: 0
  
  I ask you to discuss such issues on the freetype-devel mailing list so that you actually reach the developers.
Too late? by MMC+Monster · 2013-05-04 09:46 · Score: 1

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?

--
Help! I'm a slashdot refugee.
1. Re:Too late? by Anonymous Coward · 2013-05-04 09:54 · Score: 0
  
  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?
  There are some high DPI displays (mostly in tablets and phones) but your run of the mill pc still has normal screen (1080p) and its not even 1600x1200 or 1980x1200. So yeah even in this day and age having good font rasterizers (and good hinting technology) is a must.
2. Re:Too late? by wonkey_monkey · 2013-05-04 10:04 · Score: 1
  
  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.
  
  --
  systemd is Roko's Basilisk.
3. Re:Too late? by Longjmp · 2013-05-04 10:50 · Score: 1
  
  ... 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 (or vice versa, depends how you look at it).
  
  Currently, if you switch from one display to a better one, you may have to adjust your default font to make text readable again.
  With resolution-independent systems you'd still see the same, but the text being displayed more "crisp".
  
  *) the old "wysiwyg" concept was a hack too, because it relied on a certain physical screen/paper size to match display and printer output.
  
  --
  There are fewer illiterates than people who can't read.
4. Re:Too late? by TheRaven64 · 2013-05-04 23:15 · Score: 2
  
  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.
  
  --
  I am TheRaven on Soylent News
I'm betting it isn't gamma-aware by r00t · 2013-05-04 09:58 · Score: 1

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 the problem well. The edges shouldn't be dark. Giving equal brightness to each color, converting to greyscale should make the text fully dissapear. (identical pixel values)
1. Re:I'm betting it isn't gamma-aware by drinkypoo · 2013-05-05 01:00 · Score: 1
  
  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.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
2. Re:I'm betting it isn't gamma-aware by r00t · 2013-05-05 14:58 · Score: 1
  
  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 over to the display hardware.
  You're responding as if the OS would do something much more severe, turning that 127,127,127 into something roughly near 192,192,192. Nope, there is no normal OS that is designed for apps that assume gamma of 1.0, which is linear RGB.
More Adobe Viral Distribution Software by Anonymous Coward · 2013-05-04 12:07 · Score: 1

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?
1. Re:More Adobe Viral Distribution Software by Psychotria · 2013-05-04 13:15 · Score: 4, Informative
  
  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).
2. Re:More Adobe Viral Distribution Software by TheRaven64 · 2013-05-04 23:17 · Score: 1
  
  Ah, that's okay then, because FreeType is known to be a secure and well-written piece of software...
  
  --
  I am TheRaven on Soylent News
3. Re:More Adobe Viral Distribution Software by Anonymous Coward · 2013-05-05 02:25 · Score: 0
  
  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).
  The freetype authors are David Turner, Robert Wilhelm, and Werner Lemberg. The new rasterizer is attributed to Dave Arnold (darnold@adobe.com). Where did you get your mis-information.
4. Re:More Adobe Viral Distribution Software by Anonymous Coward · 2013-05-06 09:10 · Score: 0
  
  Yeah, I am sure your code is so much better, more secure and well-written piece of software. You are idiot.
86 DPI by dutchwhizzman · 2013-05-04 18:25 · Score: 2

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.

--
I was promised a flying car. Where is my flying car?
1. Re:86 DPI by Anonymous Coward · 2013-05-05 00:22 · Score: 1
  
  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. . .
2. Re:86 DPI by drinkypoo · 2013-05-05 00:58 · Score: 1
  
  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.
  
  --
  "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Hinting is pointless now by Anonymous Coward · 2013-05-04 18:37 · Score: 0

Having written a font hinting system (from 2 decades ago), I can say from experience that hints are pointless in this day and age. The screen resolution of Android devices and smartphones renders them pointless, and the anti-aliasing makes for the best tiny fonts anyway.
Hints always introduced annoying problems like width differences which made it difficult to match screen and printer.
Sure on a 90dpi PC less than 12pt is fuzzy due to the anti-aliasing, but then again, that just shows you how far PCs have fallen behind that they're still 90dpi.
1. Re:Hinting is pointless now by Anonymous Coward · 2013-05-05 02:42 · Score: 0
  
  Sure on a 90dpi PC less than 12pt is fuzzy due to the anti-aliasing, but then again, that just shows you how far PCs have fallen behind that they're still 90dpi.
  So in other words it is not pointless? Something is not useless based on where things should be, but where they actually are. Otherwise, might as well claim roads are pointless since we should have flying cars now.
Is this a new file format? by fgouget · 2013-05-05 11:22 · Score: 1

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?
No, the OS doesn't help at all. by Anonymous Coward · 2013-05-05 12:10 · Score: 0

There is no common OS (Linux, MacOS, Windows, etc.) that will make a pixel value of approximately 127,127,127 or 128,128,128 appear as 50% grey.
Therefore, nearly all image manipulation software needs to be gamma-aware. This includes any font rendering which involves anti-aliasing or transparancy or bitmap scaling or other blending. Nearly all software fails, resulting in normally-subtle artifacts. We live with the error, but it sucks. On rare occasions, the error can be severe.
Cost of retina display by tepples · 2013-05-09 13:34 · Score: 1

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.