Xft Hack Improves Antialiased Font Rendering

Eugenia writes: "Font antialiasing first made its way to XFree through Qt/KDE only a year ago and GTK+/Gnome followed some time after. Even with the latest version of Freetype 2.08, which reportedly brings better quality, the result is still not up to par with the rendering quality found on some commercial OSes. David Chester has hacked through the Xft library and he achieved an incredibly good quality on antialias rendering under XFree86. With this hack, at last, XFree can deliver similar aesthetic results to Mac OS X's or Windows' rendering engines. Check the two brand-new screenshots ('before' and 'after') at his web page and notice the difference with your own eyes."

Comments

good, but not quite excellent..

[thesupraman]

Having worked with GOOD font rendering software (mainly for broadcast television) I can say that most gui renderers do a pretty horrible job.

It's not that they get the font shape wrong, or don't antialias correctly, it's that they don't allow for how people see things, and just antialias 'mathmatically correct'.

With the fonts we use for television character generaters, several seperate rendering passes are used to give:
1 - a solid and anti-aliased 'interior' to the font (this is 'normal' antialiasing)
2 - a perimeter or border to the font, in a slightly different colour/darkless level, to make the edge stand out
3 - a seperate rednering to the alpha channel to stop the font from 'blending' excessivly at the edges with the background (ie: a buffer zone).

This makes a MASSIVE difference to the quality of the fonts, especially on anything other than a solid colour background.

unfortunately, no OS as yet does this for it's screen display fonts, which is a pity, as it makes a BIG difference.

Having said that, I'm VERY happy that improvements are happening, as good font rendering makes a hugh difference to the effort required to read text.

Re:good, but not quite excellent..

[thesupraman]

Hmm, I guess we don't do real time text then, damn, I was pretty sure that was what I did, certainly looks like it, I must have been dreaming...

Of course, there IS a difference when you need to display a full page of scrolling text at speed, but since characters are normally only rendered once each, and then cached, the processor time required to do high quality anti-aliased text is actually very very small in relation to just about everything else (laying out the text is a much more processor intensive task for most uses).

The time required to properly alpha-blend it is a little higher (depending on the windowing system and graphics hardware), but still not that great.

One BIG thing that gets missed is the fact that antialiasing for LCD is quite different from antialiasing for trinitron, which is quite different for antialiasing for a standard CRT, due to dot placement/shape, and that also makes quite a difference (I believe microsoft has an LCD mode, and freetype can do one, from memory).

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:ClearType?

[taion]

XFree86 4 supports sub-pixel anti-aliasing (aka ClearType). You just need to put match edit rgba=rgb; in XftConfig.

Why is font rendering in X so bad?

[lightspawn]

(half off-topic, I know).

It's like the text is always too small, too large, or not the one the developer intended.

Not to troll, but this is exactly the kind of thing that has much more effect than technical people believe.

Is it something in the design? The freely available fonts?

Greetings.

[Anonymous Coward]

Here's another mirror. Sorry about those stupid ads.

I also want emphasize one thing that I say on the website. I can't take a whole lot of credit for the improvement. For sure, the freetype project and Keith Packard, author of XRender and Xft did all of the hard work. I just tweaked a few settings (adjusted glyph proportions and turned off hinting).

David Chester

that's something completely different

[markj02]

Computer text is usually rendered onto a solid color and displayed on a high-quality, high-bandwidth device. That has almost nothing to do with rendering text for overlay onto a pictorial background and display on a low-pass, noisy device like broadcast television. Rendering text for GUIs the way you render it for television would be like slapping people in the face to get their attention and just would drive them crazy.

Anti-aliasing for computer displays is overrated anyway. Whether it helps or hurts readability depends on the font and font size, and on high resolution displays it is pointless. Printed matter isn't anti-aliased either, and printed matter is the gold standard for good looking text.

So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing. Anything else is a kludge.

Font rendering in the X server

[kcbrown]

I've asked this before, but nobody has given me a terribly good answer yet.

Why isn't font rendering done properly in the X server itself, where font rendering originally was done? Why must it be done client side?

I mean, the X server already knows what kind of visual you're trying to render to, so it's really just a question of getting the X server to pick up the necessary font information (transparency information at the edges of the letters if you insist on the X server itself not understanding how to render fonts). And the types used for the font rendering calls are all opaque anyway, so it shouldn't matter whether or not the font structure in the GC (on the server) stores additional information about the font being rendered, right?

All it would take in addition to the improved font rendering code in the X server is the definition of a new font server protocol that allows the transmission of more than just bitmap information to the X server from the font server and you'd be done, right?

So why isn't this being done instead of these client-side hacks that require magic rendering extensions (which are quite cool in and of themselves, but why should the client have to have a full set of fonts stored locally in order to do antialiased text?) ? The biggest advantage of this scheme by far is that you don't have to have any magic support for antialiased fonts in your toolkits: you get antialiased fonts for everything no matter what toolkit it's using (even Athena widgets would have antialiased text if the antialiased font rendering were done entirely server-side).

Or is this already what's being done, but I somehow missed it?

Re:Font rendering in the X server

[kcbrown]

Look, my comment is in no way a criticism of RENDER. I can see lots of advantages to having that extension, and it's excellent work.

What I'm talking about is fonts, and only fonts.

Antialiased text might be an interesting and cool use of the RENDER extension, but it's not a particularly good use, and here's why:

1. Every toolkit for which you want antialiased text must be compiled with Xft support (or whatever client-side font handler supports the RENDER extension).
2. Every client machine on which you're running an X application must not only have the above mentioned toolkits, but must also have a set of fonts to be used by the client.
3. You now have to concern yourself with whether or not the fonts are all the same on all of the client machines you're going to use.
4. If you want to use a font on multiple clients, you have to install it on all of those clients, instead of simply sticking it on the font server.
5. Since there's no guarantee that the X server supports the RENDER extension, every client (or toolkit that the client uses -- this could be included in Xft, for instance) has to have fallback code which uses the standard X font calls in case the RENDER extension is unavailable. But this is a big problem, because now you have to concern yourself with whether your font metrics (among other things) for your standard server-side fonts are the same as the ones for the fonts on the client, since the font set being used by the X server is different than the font set being used by the client.
6. Proprietary toolkits and clients (particularly those that are statically linked) gain no benefit at all -- they use non-antialiased fonts as usual.
7. All the world isn't Unix, you know. What are you going to do about those X clients that are running on systems on which your toolkits won't even compile (VMS comes to mind, outdated as it may be)? X isn't just supposed to be network-based, it's supposed to be platform independent, but this method of font handling is anything but.

The end result that I see is that client side font rendering doesn't give you any real advantages over server side rendering, with the sole exception (that I can think of, at any rate) that the client will know that the font being displayed on the screen and the font being used for printing will have the same metrics and appearance. Other than that, you take a performance hit (client has to upload the font to the server every time it wants to use it, the same font will be uploaded multiple times by multiple clients or at least multiple toolkits, since it's possible for the toolkit to cache the font locally in shared memory or something. I'm making certain assumptions about the implementation here, though), you get inconsistent font handling and rendering (what says that toolkit A will use the same font set as toolkit B?), you'll probably use a lot more in the way of server resources if you're running clients on lots of different machines, and worst of all your desktop looks really inconsistent. The only time you don't really run into most of this is when the client and server are on the same machine. While I'll admit that this is most of the time, if you're going to give up some of the advantages of a networked display system why stop there?

It seems to me that this way of handling fonts does exactly the same thing for fonts that client-side GUI toolkits does for look and feel: causes a ton of confusion, makes it difficult to get a consistent look and feel on the desktop, and causes a lot of waste in the process.

So the bottom line is that, as far as I can see, what we really need is the RENDER extension and server-side antialiased font handling. (We also need server-side toolkits, but that's a discussion for another day).

The truth

[nomis80]

Fact 1: Hinting improves font legibility at smaller sizes.

Fact 2: Freetype doesn't interpret the bytecodes in the fonts that are needed for proper hinting because of patents detained by Apple.

Fact 3: It uses an alternative bytecode "guesser". People may or may not like it, even though it usually improves legibility. This Canadian dude (I have the right to use this term because I am myself a Canadian dude ;)) only disabled the bytecode "guesser" because he didn't like it. Fine.

Fact 4: Rather than disabling the bytecode "guesser", enable the patented bytecode interpreter. Remember, this is illegal if you live in the U.S. and haven't licenced the patents from Apple.

For your enjoyment, I've made RPMs for Mandrake 8.1 and Redhat 7.2 of the Freetype library with the patented bytecode interpreter enabled.

Bill for Font Renerding Improvements

[squaretorus]

$10,000

Breakdown:
Changing 2 lines of code = $1
Knowing which 2 lines =$9,999