Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Xft Hack Improves Antialiased Font Rendering 360

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."
This discussion has been archived. No new comments can be posted.

Xft Hack Improves Antialiased Font Rendering

Comments Filter:
  • by CaptCanuk ( 245649 ) on Wednesday March 06, 2002 @02:42AM (#3116852) Journal
    I can see clearly now the fonts are antialiased...
    I can see all webpages, in my way...

  • ClearType? (Score:4, Informative)

    by Latent IT ( 121513 ) on Wednesday March 06, 2002 @02:49AM (#3116876)
    I get the feeling that there is still work to be done, though. If you have windows xp, it's worth turning on the ClearType setting in Display -> Appearance -> Effects. XP starts as anti-aliased, but ClearType brings an even greater level. Of course, if you haven't seen ClearType in action, it's hard to expect improvement from plain old win2k. But the font improvements shown above in XFree are amazing, like night and day, no more blocky p's and q's at the wrong font size, which will make a lot of happy people at non MSFT boxes. =)
    • Re:ClearType? (Score:3, Informative)

      Yes, this is true. WinXP's Clear Type is more advanced than the traditional anti-alias true type rendering, but it is valid ONLY for LCD screens, *not* for CRTs. I think this post here [] is pretty informative on Clear Type... :)
    • Re:ClearType? (Score:5, Informative)

      by taion ( 304184 ) on Wednesday March 06, 2002 @03:34AM (#3116957) Homepage
      XFree86 4 supports sub-pixel anti-aliasing (aka ClearType). You just need to put match edit rgba=rgb; in XftConfig.
    • Re:ClearType? (Score:4, Informative)

      by frantzdb ( 22281 ) on Wednesday March 06, 2002 @04:42AM (#3117080) Homepage
      With X, just add match edit rgba=rgb; to /etc/X11/XftConfig to get ClearType fonts in X.

  • by thesupraman ( 179040 ) on Wednesday March 06, 2002 @02:50AM (#3116881)

    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.
    • Unfortunately, there's a BIT of a DIFFERENCE between rendering for overlay ON video (which means you can take AS long AS you like), and DOING anti-aliasing for a semi-REAL-time user INTERfAcE.

      • by thesupraman ( 179040 ) on Wednesday March 06, 2002 @03:11AM (#3116927)

        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).
    • by markj02 ( 544487 ) on Wednesday March 06, 2002 @04:19AM (#3117051)
      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.

      • OK that has to be the most rediculous argument I've heard today: "if you want text that looks nice, get yourself a 150dpi or higher monitor". Ummm why? I'm using opera in windows XP at the moment and guess what the text looks great, if I reboot into linux and into non aliased fonts in Konqueror half the text I see will look like crap.

        You don't always have to throw hardware at a problem to solve it, that's MCSE thinking!
      • So, if you want text that looks nice, get yourself a 150dpi or higher monitor and don't bother with anti-aliasing.

        Could you please point me to the resolution independent graphics engine for Linux that would be necessary to take advantage of a 150dpi monitor?

        Otherwise it's still 72dpi, it's just that the inches are smaller than usual.

        • Check out this page [] which I just threw up. It shows the difference at the pixel level between ClearType and this guys hack.

          You can see that ClearType isn't just using grays, it's using other colors... presumably that will only make a difference on LCDs. But you can see quite clearly that ClearType is trying to get full pixels whenever it can. Look at the second leg of the 'n'... it's a gray blob with the XFree hack, but Cleartype has a solid black line.

          • This is because XP uses 'hinting' which is disabled in the xfree hack. try doing a side by side comparison of normal xfree antialiased text against XP, it should appear closer. freetype hinting is not yet as good as windows.
        • Otherwise it's still 72dpi, it's just that the inches are smaller than usual.

          This has to be the most ludicrous thing I have ever read on Slashdot.

          "My penis is 12 inches long, it's just that the inches are smaller than normal"
          • What I'm saying is that you're not increasing the effective resolution if just increase the display resolution. If your characters are 20 pixels high, and you double the screen resolution, the characters are still 20 pixels high. They are no sharper. In order to take advantage of the extra resolution you need a display engine that displays everything twice as big.

  • Slashdotted (Score:5, Informative)

    by MrP- ( 45616 ) <jessica AT supjessica DOT com> on Wednesday March 06, 2002 @02:56AM (#3116896)
    Here is a semi-mirror (no tar.gz of the hack, and the last 2 screen shots aren't there) []

    it has 2 side-by-side comparisons, and 2 shots of it in use inside applications
    • The site started to respond again so I was able to grab the last 2 shots and the tar.gz file before it died again, so the mirror is now complete.

      This is pretty cool, I'm on windows and the AA is similar, previous AA in linux (and Be, the other "alternative" :P OS ive used) gave me headaches.
  • just the hinter (Score:5, Informative)

    by Bistromat ( 209985 ) on Wednesday March 06, 2002 @03:04AM (#3116910)
    All that this guy did was disable the hinter in xft. The hinter in xft was notorious for being a piece of crap, and in fact there are makefile flags to compile it without hinting enabled. Thankfully, the next version is supposed to handle hinting, which is unique to each font, more gracefully.
  • by Anonymous Coward on Wednesday March 06, 2002 @03:14AM (#3116937)
    The site says:

    Again, please note that my changes consisted only of two lines of code worth of changes: setting some flags in freetype glyph structs, and adjusting the rendering resolution. Any praise should generally be directed to the folks at freetype and the author of Xft and XRender, Keith Packard.

    How does changing two lines of code merit a frontpage story on slashdot?

    • Did YOU ever do anything so simple who's outcome was so useful? No, of course not. Otherwise you wouldn't be so damn pissed about it. Two lines of code it may be, but the results are what got people talking about it, and in the end that's all that matters. Except to people like you, of course.

    • Do you think he got inspired by god and changed those two lines. There must be background work where he did all the tests and research about this.

      An analogy from mathematics is about how mathematicians come up with proofs to theorems. They first come up with a theorem which is a solution to a problem hoping their guess (or guesses) are correct. Then starting with the solution, step by step try to prove back to the original problem. Once they come up with a solution, it is probably 10 pages long and pretty ugly. Then they start refining the proof. At the end you have 3 lines of proof, which makes you think "How did this guy come up with this cute proof?".

      • Do you think he got inspired by god and changed those two lines. There must be background work where he did all the tests and research about this.

        Down at the bottom of the page, he shows his older method which was individually optomized for a particular font (he chose Times New Roman), and which he later abandoned. So yes, he explored at least one entire line of thought before abandoning it and apply what he had learned from that.


    • by squaretorus ( 459130 ) on Wednesday March 06, 2002 @08:06AM (#3117473) Homepage Journal

      Changing 2 lines of code = $1
      Knowing which 2 lines =$9,999
    • Anyone who has maintained a large codebase, or has made mods to someone else's code, knows this:

      Sometimes hours and hours of work can result in very few lines of code. It reminds me of the carpenter's rule: "think twice, saw once". Sometimes a great deal of analysis yields more results than many lines of code.
    • You are so right. Slashdot's standards are obviously falling. I mean, a year ago, a good hack took seven lines of code [] to merit frontpage news. Now it only takes two.

      I predict the next great hack frontpage story to be "Linux in one really huge line of Perl".

  • mine looks better (Score:3, Interesting)

    by Catmando ( 14234 ) on Wednesday March 06, 2002 @03:35AM (#3116958)
    All i can say is that my fonts look better than those screenshots. But its probably because of the sub pixel rendering on my lcd screen.

    all you have to do is add one line to your XftConfig

    here is a howto:
  • by lightspawn ( 155347 ) on Wednesday March 06, 2002 @03:45AM (#3116977) Homepage
    (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?
    • >>Not to troll, but this is exactly the kind of thing that has much more effect than technical people believe.

      Most people believe it.

      It's possible to get fonts to look correct... My fonts look fine. The real trick I think, is to get fonts working right by default.

      • by lightspawn ( 155347 ) on Wednesday March 06, 2002 @04:12AM (#3117030) Homepage
        Sure it's possible - for you. But here's a newsflash - most people, (who, by the way, know a lot more about their industries than you) don't know enough about X to configure it. And most don't have either the time or the inclination to learn.

        So how the OS is shipped determins how good the fonts look for most people. If you can make it look better, make that the default.

        The goals of "making everybody see the light and switch to Linux, thus toppling micro$oft" and "forcing every Linux user to spend hundreds of hours learning about the system" are MUTUALLY EXCLUSIVE.
    • Check out the XFree86 Font De-uglification HOWTO [].

      It has a lot of information on font rendering in X11 and following its advice can really make a big difference in improving the look of the fonts, (especially in Netscape I found).


  • Greetings. (Score:5, Informative)

    by Anonymous Coward on Wednesday March 06, 2002 @03:54AM (#3116993)

    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

  • by koekepeer ( 197127 ) on Wednesday March 06, 2002 @03:58AM (#3117003)
    it might just be a typical "ignorance is bliss" situation on my side, but if this effect was largely achieved by disabling the (apparently buggy) hinting support in freetype, why did they enable it in the first place?

    i'm not trying to insult the freetype guys, they've done great work to make X look nicer, but this hack would probably not exist if they would have disabled hinting by default.

    the screenshots do look okay, but are still somewhat blurry. i actually prefer not using antialiasing below 10pt anyway, the fonts quickly become unreadable. but that IMHO of course.
  • AA text fuzzy? (Score:4, Insightful)

    by rubinson ( 207525 ) <> on Wednesday March 06, 2002 @04:08AM (#3117020) Homepage
    I'm really not trying to troll here but anti-aliased text has always looked fuzzy to me. In the screen shots, for example, the spacing and sizing of the AA text is certainly nicer but the default text seems shaper and crisper. Am I wrong here? Joel Spolsky agrees with me [] but everyone else seems so excited about AA text that I have to wonder if I'm missing something.
    • I would agree, then I started using WinXP and cleartype. Cleartype amazed me when I first saw it, it is perfect anti-aliasing.

      I cant wait to see something like this as standard on linux. My work computer is a sunblade 100 running linux, Only thing that it needs is good AA fonts.
    • It really depends on your monitor and the settings on your video card. I've had configurations where the AA looked better, and others (most) where I prefered just having nonantialiased best. The antialiased icons in KDE, however, look great. But then, I'm not looking for the details nor demanding instant recognition of many dozens of them per second.


    • AA has always been a matter of preference. My first computer had RISC OS on it, which had anti-aliased font rendering by default from the get-go. I guess I just got used to it and expect it. The one place I don't like AA is in my X terminals, which is funny since the one place RISC OS never had anti-aliasing was its command line :)
    • I agree that those screen shots look blurry, but if you get used to the anti aliasing on Windows 2000, which only does larger fonts, it is definitely an improvement. I have friends with laptops (LCD's) and XP, and they absolutely love ClearType. So I think it's a combination of getting used to it (it won't look good immediately, since you are used to sharp, jagged edges) and getting a decent font renderer (which Linux may or may not have). Give yourself a few days of it and see if it looks better to you. You might end up wishing you'd done that a long time ago.
    • With this hack, if the edge of a character goes straight down the middle of a pixel, the pixel is lit up at 50% brightness. That means if you have a 1px wide black line that straddles the border between pixels, you end up seeing a 2px wide gray line. On the other hand, without AA, the renderer forces the line to one side or the other, which is where the aliasing comes from.

      ClearType takes something a of a middle of the road approach. It takes the hinting into account, trying to push things towards pixel borders when it can, but not forcing it too much. This is what XFree does by default, the only thing is that it does the hinting rather poorly, so you still see a lot of the effects of "forcing" the text towards the pixel boundaries.

      Evil empire or not, ClearType on a CRT is by far the cleanest AA screen displayed type I've ever seen. I imagine it's even sharper on an LCD. I can't wait for Linux to develop a competetive solution (we're almost there!)

    • I have to agree 100% here...

      I always feel like Im looking at one of those 'are you stoned ?' t shirts with blury text.

      I have been hammering away at aconsole since 79, I have 20-20 vision in my 30's and have singularly NEVER gotten a headache from looking at a screen to long, I hated when ambers came out I like green.

      But you are not alone, everytime Im looking at AA I try to focus.

      Your not missing anything, who is anyone to tell you youre wrong, like the old myopic lady that has her fonts jacked up to the size of playing cards, it works for her.

      NOW This is true on a screen, this is transient infromation, mine isnt up long enough to have to look good.
    • You're not trolling as quite a lot of people just do not like AA text, even in the Mac world.

  • by Proc6 ( 518858 ) on Wednesday March 06, 2002 @04:15AM (#3117041)
    Why can't people see the real answer is just to develop ultra high resolution displays finer than the resolution of the human eye, then we can just make razor sharp fonts like a high quality laser printer. :) Okay, so we'd need a 4gig GeForce20 Ultra, but it would look 3R33T.
  • by colmore ( 56499 ) on Wednesday March 06, 2002 @04:23AM (#3117058) Journal
    This really isn't meant to be a flame.

    This seems to me to be a technology of limited use. Even at high screen resolutions almost all text is rendered at 12 pt, at which size anti-aliasing is more or less worthless.

    It makes title bars look pretty. It makes big text on web pages look pretty. But for 99% of the text you see, it doesn't do much.

    I don't want to discount the effort. I mean, if this program is as good as the screenshots suggest, then excellent job. (I haven't been able to test it out myself yet)

    I guess I'm just not used to the modern computing era when it really is possible to throw in everything and the kitchen sink. I've gotta keep reminding myself that if something takes up an extra meg of Ram/swap and thirty megs of drivespace, that really doesn't matter. All of my instincts are still roughly in the 486 era, and I still think "why?" at every feature.

    I just think at this point, the opensource community needs to give up its right to accuse others of bloatware. Bloatware is the modern standard, and if we don't embrace it, we look feature-poor. But Linux in the form that nearly everyone sees it and uses it today is bloatware. Well designed bloatware, for the most part, but bloatware nontheless.
    • But for 99% of the text you see, it doesn't do much.

      When using fonts not specifically designed for low-res (300dpi and under) it does make a big difference; I find the web really clear in GillSans but without AA Gill just turns into blobs in many situations.


    • This really isn't meant to be a flame.

      This seems to me to be a technology of limited use. Even at high color depths almost all text is rendered as black-on-white, which makes color pretty much worthless.

      It makes title bars look pretty. It makes big pictures on web pages look pretty. But for 99% of the text you see, it doesn't do much.

      reducto ad absurdum

  • by kcbrown ( 7426 ) <> on Wednesday March 06, 2002 @04:47AM (#3117089)
    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?

    • by Adnans ( 2862 ) on Wednesday March 06, 2002 @05:04AM (#3117117) Homepage Journal
      This [] might explain why client-side rendering was chosen. There are pros and cons but the pros seem to outweight the cons by far.

      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

      This doesn't seem to be a problem since most populair toolkits already support the Render extension. Remember, RENDER is a completely new rendering system for X, not just anti-aliasing.

      ...even Athena widgets...

      If there was great demand for this it would already have happenend don't you think? Changing the Xaw toolkit to support RENDER would not be too hard I think.

      • by kcbrown ( 7426 ) <> on Wednesday March 06, 2002 @07:34AM (#3117411)
        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).

        • I agree. Your last remark (the need for server-side toolkits) also hits home IMHO, and I'd suggest a few more things for them:

          1. the elements in these toolkits must be able to be defined in terms of server primitives orother elements, using a platform independent special-purpose language. And not only their appearance but also where simple interactions are concerned, such as a 'down' button that moves a slide down and a scrollable view up;

          2. the server must be able to receive these definitions from the client itself or to fetch it from an external source on behalf of the client (honor server security by making sure the definition language's scope is limited to the user interface only);

          3. the server must be able to cache these elements using unique identifiers by which they can be referenced. These should have two parts: a functional part and an appearance part. Clients specify an element's functional part as a requirement, and its appearance part as a hint, in order for users to be able to provide alternatives (i.e. theme support);

          4. a proper encryption and authentication model for the X channel.

          This makes the server able to operate more independently, instead of requiring a round trip to the client for every simple operation, making operation over low-security, low-bandwith, high-latency networks such as the internet *much* more practical.

          Potentially, this would provide a lot more elegant distributed computing model than the whole mess we have now for exporting user interfaces, with http, html, the DOM, jscript and all those gross hacks that seem impossible to get right if you look at today's browsers.

          What do you think?
        • Sun is working on advanced font rendering and layout in the X server. The project is still in the early stages of development, but since it's open source, you can see what's there so far at [].
    • I'm no XFree expert, but this is what I think is going on.

      The anti-aliasing is a small part of what is the XRender extension. XRender is not so much an ordinary extension but a whole new rendering system the XFree developers are developing.

      The standard X11 protocol requires 1-bit bitmapped fonts and the XFree team couldn't just up and break it so fundamentally, so they did XRender. While they were at it, they implimented things like alpha-blending (Which is pretty much needed for proper AA anyway) and some other things, but I don't know specifics.

      The AA has gotten a lot of attention simply because it solved a major shortcoming of X, whereas the others are just nice.

      Now, because the AA is part of XRender and not a replacement font subsystem, each individual toolkit has to be adapted to use The XRender font system, as opposed to the normal X11 font subsystem. With the advent of GNOME2, both major toolkits will have support for AA fonts, which is good enough for me :)
      • The standard X11 protocol requires 1-bit bitmapped fonts and the XFree team couldn't just up and break it so fundamentally, so they did XRender. While they were at it, they implimented things like alpha-blending (Which is pretty much needed for proper AA anyway) and some other things, but I don't know specifics.

        I haven't looked at the X protocol itself, but the Xlib call to draw text on the screen is XDrawString() and XDrawText(). In both cases, you use a GC specifier, and the GC itself is what contains which font you want to use to perform the text drawing operation.

        While the documentation may specify how exactly fonts are drawn, the GC is an opaque data type. That implies that it should be possible to change its internal representation on the server without any client-side consequences (I'm assuming that the GC really is a server side construct and not an Xlib construct).

        But if you must make client-side changes in order to support antialiased fonts, there's only one proper place to do it: Xlib itself. At least then you'll automatically get antialiased font support in all of your toolkits on that client, without having to change a thing in those toolkits (because you can change the Xlib implementations of XLoadFont(), XDrawString(), etc., as needed).

  • by malice ( 82026 ) on Wednesday March 06, 2002 @06:52AM (#3117334) Homepage
    For comparison sake, here are screenshots of the same page using Mac OS X's font smoothing. I wasn't able to get a font size that matched the screenshot exactly, so made two: a smaller font than the Xtf hack image, and a larger font then the Xtf image:

    Overall, the Xtf hack does look quite nice. To my eye, the OS X renderings are still a bit more aesthetically pleasing, but the Xtf hack definitely improves things quite a bit.

  • Maybe it's because I'm using subpixel rendering
    on my LCD screen right now, but the 'after' images
    look much worse than the regular XFT rendering to
  • The truth (Score:5, Interesting)

    by nomis80 ( 181676 ) <nomis80.nomis80@org> on Wednesday March 06, 2002 @07:56AM (#3117453) Homepage

    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.

    • Are the rpms you provide simply the result of changing line 378 of include/freetype2/config/ftoption.h, to #define TT_CONFIG_OPTION_BYETCODE_INTERPRETER?

      My distribution happens to do that by default :) Some fonts still look really ugly, but better than that auto-hinting crap.
    • Those patents are kinda hard to read. Maybe them should have used the hinting technology to print it ;-)
  • by heroine ( 1220 ) on Wednesday March 06, 2002 @09:42AM (#3117795) Homepage
    Sometimes I wish instead of cleartype that Microsoft advertized 3 years ago it was 3D graphics or something because even though there seems to be more to life than font rendering, most people don't know what's important without Microsoft to lead the way. Now that we have to spend our existances getting the absolute best approximation to cleartype it's like Microsoft advertizes exactly what doesn't matter so their competition doesn't beat them at what does matter.

  • Well, I must say that at larger sizes, I much prefer the original `hinted' text, since it shows up much darker on my display. However, the non-hinted text seems to be much more legible at smaller sizes, and it definitely scales much more cleanly (no jumping from everything being ~1 pixel wide to everything being ~2 pixels).

    If the non-hinted text could be made darker, that would be great! Of course, I hear that the hinting engine is getting better and better, so who knows what will be the best a year from now..
  • If you want to accomplish something similar, before compiling freetye, look at line 435 of include/freetype/config/ftoption.h in the source distribution before compiling. That disables the hinter. I'm not if this is as effective as what the guy did to the Xft library. I don't have the orginal source files at the moment, so I can't tell exactly what he changed. I also can use his libXft.

    Another option is to realize that the hint guessing that freetype does to avoid patent infringement problems by default can be changed to use a bytecode interpreter that does proper hinting of TrueType fonts, Change line 378 of the above mentioned file for this to occur. I still don't understand how making the code "optional" makes it any less patent infringing..

    Of course, no matter how you configure freetype, it will still look like crap without good fonts. has a script to automate installation of Microsoft true type fonts.

    Of course by enabling the bytecode interpreter and *possibly* by getting MS fonts without a MS OS, you may be doing illegal stuff, but if pretty fonts under X is outlawed, then only outlaws will have pretty fonts under X, or something like that....

    Disabling hinting with the default fonts is probably the most legal way to go, but what is the fun in that?

  • The only AA font system I have ever liked, is the old RiscOS AA. It rendered the font very well. They where clear, (MS AA is worse), precise, (RiscOS used 'sub-pixel AA, which made different looking characters pixel-wise, but looked the same on screen. Just type 'iiiiiiiiiiiiii' in the Times font into Word/Mozilla) and it was very configurable; Anti-alising, hinting etc. could all be set by the user. The MacOS X fonts look similar, but I still have to see them in action.
  • by Theovon ( 109752 ) on Wednesday March 06, 2002 @11:49AM (#3118656)
    People in the XFree project may already be considering this, but antialiased objects look much better when you take into consideration that a gray ramp that is perceptually linear is not optically (luminously?) linear.

    To be specific, imagine you're drawing an antialiased line, and you have come to a point where the line covers 50% of two adjacent pixels, so you decided to paint them both with 0x7f. The problem there is that a pixel that looks like 50% gray is actually emitting 18% as much light as a full-on pixel, so when you put the two 18% pixels together, they add up to 36% instead of 100%. The result is that a thin antialiased line will appear to get darker and lighter along its length. If you were to take this into account, it might improve antialiased text further.

    The function to apply to all pixels is this, where x is a number from 0 to 255 representing the brightness you WANT to get, and y is what you have to plot:
    y = (int)(255.0 * pow(x/255.0, 1/2.5) + 0.5)

    The +0.5 rounding factor in there may not affect much.

    I believe it was a Dr. Poynton who talked at length about this in the 1998 Siggraph.

  • blurry text (Score:3, Insightful)

    by Mr. Slippery ( 47854 ) <> on Wednesday March 06, 2002 @02:05PM (#3119697) Homepage
    With this hack, at last, XFree can deliver similar aesthetic results to Mac OS X's or Windows' rendering engines.

    Ah, so blurry text is an "aesthetic result"?

    "Anti-aliasing" just means blurring [], and is in general not a good thing. And this particular hack turns off hinting, to make it every blurrier.

    Like headaches? Install this.

  • by johnrpenner ( 40054 ) on Wednesday March 06, 2002 @02:37PM (#3119882) Homepage
    when it comes down to it, HERE's [] an actual Mac OS9 screenshot to compare to the Xfree anti-aliasing. notice that OS9 doesn't anti-alias text below (user settable) 12 points (handy, and faster). i've set the browser font to be: Times-12 -> imo, after examining both the X shot and this shot at 400% magnification, it seems to me that the hinting and definition of the MacOS still yields clearer text. someone might also want to post up a OS-X and XP screenshot of the same web page: e/index.html [] so we can have a REAL comparison of actual screenshots instead of a lot of /. theorizing about about the Nyquist limit. regards, johnrpenner [].
  • by Performer Guy ( 69820 ) on Wednesday March 06, 2002 @11:22PM (#3122739)
    This is great stuff, well done. It is also a perfect illustration of the dangers of using a misunderstood technology; hinting. Hinting was originally designed to help non antialiased fonts shift character vectors to align with discrete pixels for a more recognizable character description. It's application to antialiased fonts was foolish and never worked because the antialiasing is perfect for displaying the subpixel hint shifts being applied and makes the fonts look extremely ugly. Hinting on antialiased fonts was a complete misapplication of an earlier display kludge.

    This work illustrates this perfectly. No need for debates, look at the images and learn. Well done and kudos for an awesome and simple piece of work.

"This is lemma 1.1. We start a new chapter so the numbers all go back to one." -- Prof. Seager, C&O 351