Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Google and Adobe Contribute Open Source Rasterizer to FreeType

timothy posted about a year and a half ago | from the fonts-matter dept.

Graphics 77

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.

Sorry! There are no comments related to the filter you selected.

I hope it is not... (1)

Anonymous Coward | about a year and a half ago | (#43630775)

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:I hope it is not... (3, Interesting)

dosius (230542) | about a year and a half ago | (#43630819)

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... (1)

Anonymous Coward | about a year and a half ago | (#43630943)

No.

Re:I hope it is not... (1)

aliquis (678370) | about a year and a half ago | (#43631407)

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.

Re:I hope it is not... (2)

bill_mcgonigle (4333) | about a year and a half ago | (#43634171)

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.

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

Samantha Wright (1324923) | about a year and a half ago | (#43630831)

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... (3)

anss123 (985305) | about a year and a half ago | (#43630951)

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:I hope it is not... (1)

Samantha Wright (1324923) | about a year and a half ago | (#43631075)

Well, there are still a lot features like hinting and sub-pixel smoothing that were added on later.

Re:I hope it is not... (3, Informative)

MrHanky (141717) | about a year and a half ago | (#43631423)

One of the most significant patents (owned by Apple) expired just a few years ago [techrights.org] . 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...

I wrote a CFF renderer in C# (4, Interesting)

anss123 (985305) | about a year and a half ago | (#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.)

Re:I wrote a CFF renderer in C# (2)

Intrepid imaginaut (1970940) | about a year and a half ago | (#43630823)

What is hinting in this context?

Re:I wrote a CFF renderer in C# (2)

wootest (694923) | about a year and a half ago | (#43630885)

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

flargleblarg (685368) | about a year and a half ago | (#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# (4, Informative)

anss123 (985305) | about a year and a half ago | (#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).

Re:I wrote a CFF renderer in C# (-1, Offtopic)

Longjmp (632577) | about a year and a half ago | (#43630907)

What is hinting in this context?

I think he meant tinting.
And indeed, once you avoid tinting the fonts, rendering becomes very easy!
;-)

Re:I wrote a CFF renderer in C# (0)

Anonymous Coward | about a year and a half ago | (#43630959)

You're either trying to be funny or a blathering idiot. Could you give us a hint?

Re:I wrote a CFF renderer in C# (0)

flimflammer (956759) | about a year and a half ago | (#43631069)

The wink should have been obvious that he was kidding.

Re:I wrote a CFF renderer in C# (0)

Longjmp (632577) | about a year and a half ago | (#43631177)

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. ;-)

Re:I wrote a CFF renderer in C# (1)

MysteriousPreacher (702266) | about a year and a half ago | (#43634821)

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.

Re:I wrote a CFF renderer in C# (1)

gigaherz (2653757) | about a year and a half ago | (#43630993)

You could describe it as "guided pixel snapping".

Re:I wrote a CFF renderer in C# (1)

jonbryce (703250) | about a year and a half ago | (#43630969)

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

Re:I wrote a CFF renderer in C# (2)

anss123 (985305) | about a year and a half ago | (#43631037)

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# (1)

tlhIngan (30335) | about a year and a half ago | (#43642859)

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.

Re:I wrote a CFF renderer in C# (1)

femtobyte (710429) | about a year and a half ago | (#43632857)

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.

Cost of retina display (1)

tepples (727027) | about a year and a half ago | (#43681469)

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.

Re:I wrote a CFF renderer in C# (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#43631333)

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:I wrote a CFF renderer in C# (2)

anss123 (985305) | about a year and a half ago | (#43631431)

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# (1)

K. S. Kyosuke (729550) | about a year and a half ago | (#43631511)

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.

Re:I wrote a CFF renderer in C# (1)

anss123 (985305) | about a year and a half ago | (#43631595)

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.)

Re:I wrote a CFF renderer in C# (1)

TheSeatOfMyPants (2645007) | about a year and a half ago | (#43632995)

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.

Re:I wrote a CFF renderer in C# (1)

phantomfive (622387) | about a year and a half ago | (#43631507)

Sweet, I always wondered how hard it would be to make my own font renderer.

Hinting is pointless now (0)

Anonymous Coward | about a year and a half ago | (#43633167)

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.

Re:Hinting is pointless now (0)

Anonymous Coward | about a year and a half ago | (#43634409)

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.

Nice (-1)

Anonymous Coward | about a year and a half ago | (#43630815)

This is nice.

Metafont (1)

foobsr (693224) | about a year and a half ago | (#43630833)

tug.org/tug2008/abstracts/tug08abstracts.pdf

CC.

Re:Metafont (1)

Anonymous Coward | about a year and a half ago | (#43634011)

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.

Re:Metafont (0)

Anonymous Coward | about a year and a half ago | (#43634467)

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! (0)

Anonymous Coward | about a year and a half ago | (#43630841)

Can't wait for this to be rolled into a Linux distro. :)

Meh , fonts. Big deal. (1)

Viol8 (599362) | about a year and a half ago | (#43631035)

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. (4, Informative)

anss123 (985305) | about a year and a half ago | (#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:Meh , fonts. Big deal. (1)

jfengel (409917) | about a year and a half ago | (#43631123)

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

Re:Meh , fonts. Big deal. (3, Informative)

Dan East (318230) | about a year and a half ago | (#43631565)

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.

86 DPI (2)

dutchwhizzman (817898) | about a year and a half ago | (#43633145)

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

Anonymous Coward | about a year and a half ago | (#43633869)

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. . .

Re:86 DPI (1)

drinkypoo (153816) | about a year and a half ago | (#43633987)

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.

Re:Meh , fonts. Big deal. (0)

Anonymous Coward | about a year and a half ago | (#43632007)

> TrueType/CFF are based on vectors

No, they are based on Bezier curves.

Re:Meh , fonts. Big deal. (0)

Anonymous Coward | about a year and a half ago | (#43631079)

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.

Re:Meh , fonts. Big deal. (1)

flimflammer (956759) | about a year and a half ago | (#43631083)

lolwut.

Re:Meh , fonts. Big deal. (0)

Anonymous Coward | about a year and a half ago | (#43631275)

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.

Re:Meh , fonts. Big deal. (1)

Mprx (82435) | about a year and a half ago | (#43633175)

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.

Re:Meh , fonts. Big deal. (1)

lattyware (934246) | about a year and a half ago | (#43631305)

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.

Re:Meh , fonts. Big deal. (1)

H0p313ss (811249) | about a year and a half ago | (#43631429)

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! (1, Interesting)

Anonymous Coward | about a year and a half ago | (#43631319)

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.)

Re:Great! Now fix TrueType! (0)

Anonymous Coward | about a year and a half ago | (#43631359)

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.

Re:Great! Now fix TrueType! (1)

VortexCortex (1117377) | about a year and a half ago | (#43633479)

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.

I'm betting it isn't gamma-aware (1)

r00t (33219) | about a year and a half ago | (#43631575)

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)

Re:I'm betting it isn't gamma-aware (1)

drinkypoo (153816) | about a year and a half ago | (#43633993)

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.

No, the OS doesn't help at all. (0)

Anonymous Coward | about a year and a half ago | (#43637469)

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.

Re:I'm betting it isn't gamma-aware (1)

r00t (33219) | about a year and a half ago | (#43638421)

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.

Re:Great! Now fix TrueType! (3, Interesting)

Psychotria (953670) | about a year and a half ago | (#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:Great! Now fix TrueType! (1)

caseih (160668) | about a year and a half ago | (#43632891)

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.

Re:Great! Now fix TrueType! (1)

PhrostyMcByte (589271) | about a year and a half ago | (#43632309)

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.

Re:Great! Now fix TrueType! (1)

inglorion_on_the_net (1965514) | about a year and a half ago | (#43632635)

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!

Re:Great! Now fix TrueType! (1)

yuhong (1378501) | about a year and a half ago | (#43632931)

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

Re:Great! Now fix TrueType! (0)

Vegemeister (1259976) | about a year and a half ago | (#43633979)

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

Re:Great! Now fix TrueType! (0)

Anonymous Coward | about a year and a half ago | (#43645361)

I ask you to discuss such issues on the freetype-devel mailing list so that you actually reach the developers.

Too late? (1)

MMC Monster (602931) | about a year and a half ago | (#43631525)

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?

Re:Too late? (0)

Anonymous Coward | about a year and a half ago | (#43631559)

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.

Re:Too late? (1)

wonkey_monkey (2592601) | about a year and a half ago | (#43631591)

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:Too late? (1)

Longjmp (632577) | about a year and a half ago | (#43631727)

... 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.

Re:Too late? (2)

TheRaven64 (641858) | about a year and a half ago | (#43633689)

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.

More Adobe Viral Distribution Software (1)

Anonymous Coward | about a year and a half ago | (#43632055)

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?

Re:More Adobe Viral Distribution Software (4, Informative)

Psychotria (953670) | about a year and a half ago | (#43632287)

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).

Re:More Adobe Viral Distribution Software (1)

TheRaven64 (641858) | about a year and a half ago | (#43633697)

Re:More Adobe Viral Distribution Software (0)

Anonymous Coward | about a year and a half ago | (#43647271)

Yeah, I am sure your code is so much better, more secure and well-written piece of software. You are idiot.

Re:More Adobe Viral Distribution Software (0)

Anonymous Coward | about a year and a half ago | (#43634329)

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.

Is this a new file format? (1)

fgouget (925644) | about a year and a half ago | (#43637225)

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?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?