Slashdot Mirror


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

46 of 336 comments (clear)

  1. Breaks out in song... by CaptCanuk · · Score: 3, Funny

    I can see clearly now the fonts are antialiased...
    I can see all webpages, in my way...

    --
    ---- The geek shall inherit the Earth.
  2. ClearType? by Latent+IT · · Score: 4, Informative

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

    1. Re:ClearType? by Eugenia+Loli · · 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... :)

    2. Re:ClearType? by taion · · Score: 5, Informative

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

      --

      ----------
      Floccinaucinihilipilification - the action or habit of judging something to be worthless
    3. Re:ClearType? by frantzdb · · Score: 4, Informative

      With X, just add match edit rgba=rgb; to /etc/X11/XftConfig to get ClearType fonts in X.

      --Ben

  3. good, but not quite excellent.. by thesupraman · · Score: 5, Informative


    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.

    1. Re:good, but not quite excellent.. by thesupraman · · Score: 5, Informative


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

  4. Comment removed by account_deleted · · Score: 5, Informative

    Comment removed based on user account deletion

  5. Changing two lines of code is "hacking through"? by Anonymous Coward · · Score: 3, Insightful
    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?
  6. mine looks better by Catmando · · Score: 3, Interesting

    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:
    http://jmason.org/howto/subpixel.html

  7. Why is font rendering in X so bad? by lightspawn · · Score: 5, Interesting

    (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?

    1. Re:Why is font rendering in X so bad? by Error27 · · Score: 3, Informative
      >>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.

    2. Re:Why is font rendering in X so bad? by lightspawn · · Score: 4, Insightful

      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.

  8. Greetings. by Anonymous Coward · · Score: 5, Informative


    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

  9. Re:Steve Gibson debunks M$'s "innovation" by spectecjr · · Score: 3, Insightful

    Check out this article [grc.com]. ClearType is just Microsoft's name for sub-pixel rendering, and it's been around for decades now.

    Yeah, but Gibson is also an ass who doesn't seem to know the difference between scientific method and guesswork.

    MS research has the fully detailed papers which indicate the fourier transforms, information theory and signal processing theory behind the technique. Which is a damn sight more thorough than Gibson's quackery.

    "Oh yeah, apple did it all in the 70s". Bullshit. Back then, the Apple II didn't have the hardware or the CPU power to do the kind of calculation you need to do for Cleartype. Nor did it have the color resolution. All Apple's tech was was a way of hacking color out of a monochrome NTSC signal -- not getting better resolution out of a monochrome signal using color. Get the difference?

    When are people around here going to do some thinking and some research instead of acting like idiots? I thought that people who flock to sites like this were supposed to be tech savvy? Maybe it's just me, but I thought that indicated at least a modicum of intelligence instead of blind sheepery.

    Simon

    --
    Coming soon - pyrogyra
  10. erm... why is hinting enabled then? by koekepeer · · Score: 4, Insightful

    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.

  11. AA text fuzzy? by rubinson · · Score: 4, Insightful

    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.

    1. Re:AA text fuzzy? by frantzdb · · Score: 3, Informative

      It is available for X. See my other post on this page.

      --Ben

  12. Font antialiasing is a crutch by Proc6 · · Score: 4, Funny

    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.

    --

    I'm Rick James with mod points biatch!

  13. that's something completely different by markj02 · · Score: 5, Insightful
    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.

  14. Xft and fontconfig by po8 · · Score: 4, Informative

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

    Ah, how intuitive... how many hours of reading manpages, HOWTOs and FAQs did it take to figure that one out?

    Be patient. Keith Packard is pretty well done with his design and implementation of a new font selection configuration mechanism currently known as "fontconfig". Fontconfig separates the font selection from the rest of Xft, allowing other applications such as printer drivers to select fonts using the same mechanism and policy as X applications.

    In the process, fontconfig replaces the arcane Xft configuration language with an XML DTD. This should allow easier hand-editing of this configuration. More importantly, it should allow GUI toolkits such as KDE and Gnome to easily put a GUI interface on font selection configuration. Hopefully, in a few months you'll be able to just click a button to get sub-pixel font rendering with Xft.

  15. Kinda sorta bloatware by colmore · · Score: 3, Insightful

    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.

    --
    In Capitalist America, bank robs you!
  16. Font rendering in the X server by kcbrown · · Score: 5, Interesting
    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?

    --
    Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
    1. Re:Font rendering in the X server by Adnans · · Score: 4, Informative

      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.

      -adnans

      --
      "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
    2. Re:Font rendering in the X server by kcbrown · · Score: 5, Insightful
      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).

      --
      Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
    3. Re:Font rendering in the X server by evbergen · · Score: 3, Interesting

      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?

      --
      All generalizations are false, including this one. (Mark Twain)
    4. Re:Font rendering in the X server by acoopersmith · · Score: 3, Informative

      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 http://stsf.sourceforge.net/.

  17. Re:Linux/X86 configuration standard needed bad by taion · · Score: 3, Interesting

    Ah, but you see... I _don't_ use Linux. I use FreeBSD, and that trick is marked _quite_ clearly in the FreeBSD handbook in the fonts subsection of the X section.

    <evangelism>
    I haven't had any problems with finding FreeBSD documentation, actually. Practically everything is on the FreeBSD website or one of its mailing lists, so I don't experience problems here.

    On the other hand, I get to build everything from source, so I need to do everything for hours upon hours anyway! (:
    </evangelism>

    --

    ----------
    Floccinaucinihilipilification - the action or habit of judging something to be worthless
  18. Re:Linux/X86 configuration standard needed bad by Adnans · · Score: 4, Informative

    Ah, how intuitive... how many hours of reading manpages, HOWTOs and FAQs did it take to figure that one out?

    It could have taken you one Google search for "xfree86 subpixel rendering" to find this link!

    -adnans

    --
    "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
  19. Re: Shitty browser by HeUnique · · Score: 4, Informative

    On the contrary...

    If there is a browser that you got a chance to see an IE only web site is Konqueror on KDE 3.0 - it got the most compatible with MSIE javascript and rendering techniques...

    --
    Hetz (Heunique)
  20. Disabling hinting is NOT the way to go by Johan+Veenstra · · Score: 4, Insightful

    This guy just disabled hinting and adjusted the rendering resolution to his liking.

    Without hinting, fonts will never look as good as they do on MS Windows or OS X.

    Messing with the rendering resolution to make certain fonts look a little bit better seems to be the kind of hacking a chicken without a head could do.

    This is not the ueberhack slashdot makes it out to be. This is not news.

    regards,

    Johan V.

    1. Re:Disabling hinting is NOT the way to go by BigSven · · Score: 3, Informative

      Actually the result of hinting depends on two things. First, the font needs to be hinted well. Unfortunately only very few fonts are well-hinted. For those that aren't it makes indeed sense to turn hinting off entirely. Second, your font renderer needs to support the hinting information embedded into the font.

      TrueType fonts have bytecode with hinting information that can be interpreted by the renderer. This is what freetype-2.0 did up to version 2.0.1. Due to patent issues this feature was turned off by default in version 2.0.2. All newer versions of freetype use something what they call autohinter. While this gives better results for badly hinted or unhinted fonts, it does not (yet) achieve the excellent results you get from using the hints embedded in well-hinted fonts.

      The solution is thus not to disable hinting but to enable the bytecode interpreter in your freetype2 libs. Of course you also need some decent fonts.

    2. Re:Disabling hinting is NOT the way to go by daw · · Score: 3, Informative

      It's true, disabling hinting is just plain stupid. The real problem is that TrueType font hinting is patented (by Apple!) and so though the freetype library (used by Xft for font rendering) has the code to do it properly, it's disabled by default in favor of an "automatic hinting engine" that probably makes things worse. So I'm not surprised that disabling hinting in a default build of freetype makes things look better. But it's a really dumb way to proceed.

      The right solution is to recompile freetype with the patented hinting turned ON, and the automatic hinting engine turned OFF. It really looks good, way better than either of that guy's screenshots.

  21. Re:that's something completely different, -1 cluel by markj02 · · Score: 4, Insightful
    Bzzzt. Printing is analog, it's naturally anti-aliased.

    Well, maybe that's what they tell the arts majors. However, the term "aliasing" actually refers to what happens when you try to exceed the Nyquist limit: different frequencies are "aliased" together. Anti-aliasing removes that by band-limiting the signal in some way prior to sampling. When you print with toner on paper, there is nothing band-limited about the resulting image: the toner/paper transition has very high contrast edges at just about any resolution you care to look and those result in very high frequency components in the image.

    the fact the the text doesn't look butt-ugly as usual.

    You demonstrate a common occupational hazard for people working in graphics: you prefer style over function.

    Think about anti-aliased text on a 150 dpi monitor.

    For most monitors, you wouldn't even be able to tell the difference. And for a high-resolution monitor designed to display text, you make the display worse if you try to anti-alias.

    Usually. What about when it isn't?

    If you composite onto an image, the text needs to undergo the same filtering as the the image has undergone or it will look unnatural. In the case of compositing text into television images, there happens to be a single answer because, by convention, television cameras try to degrade the image in roughly the same traditional way. For digital images you find on computers, the filter could be anything.

  22. The truth by nomis80 · · Score: 5, Interesting

    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.

  23. Bill for Font Renerding Improvements by squaretorus · · Score: 5, Funny

    $10,000

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

  24. What does Microsoft want us to obsess over today? by heroine · · Score: 3, Interesting

    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.

  25. Re:Steve Gibson debunks M$'s "innovation" by saintlupus · · Score: 3, Interesting

    I thought that people who flock to sites like this were supposed to be tech savvy? Maybe it's just me, but I thought that indicated at least a modicum of intelligence instead of blind sheepery

    You're obviously not in my first-year CS courses. Maybe its because I'm coming back to school several years older than my classmates, but christ, they're pretty clueless about technology.

    If one more of them says he's in CS because programming pays well, I'm going postal.

    --saint

  26. Don't you mean... by Junta · · Score: 3, Funny

    that you take your glasses *off* to anti-alias fonts? :)

    --
    XML is like violence. If it doesn't solve the problem, use more.
  27. Re:Anti-aliasing is here to stay. by foobar104 · · Score: 3

    Those high-res printers you speak of, still use anti-aliasing.......

    No, they don't. A dot on paper is either there, or it isn't. You don't print with multiple shades of grey and black ink to give the illusion of higher resolution. Around the 200 DPI mark, printed text takes on the appearance of smooth letterforms, not patterns of dots. Of course, you can tell the difference between 200 and 2400 DPI easily, but the point is that 200 DPI is where you stop seeing the pixels before you see the letters.

    You may be thinking of halftones, which are patterns of dots of various sizes that can achieve the illusion of tone when viewed from a reasonable distance. This isn't anti-aliasing at all.

    And by the way, an ellipsis has three dots, like this: ...

  28. Gamma curves and antialiasing by Theovon · · Score: 4, Insightful

    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.

    Thanks.

    1. Re:Gamma curves and antialiasing by spitzak · · Score: 3, Informative
      The sRGB standard is this (sorry it ate the lessthan sign):

      V = B < .04045 ? v/12.92 : pow((v+.055)/1.055, 2.4)

  29. Re:Changing two lines of code is "hacking through" by dark_panda · · Score: 3, Funny

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

    J

  30. blurry text by Mr.+Slippery · · Score: 3, Insightful
    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.

    --
    Tom Swiss | the infamous tms | my blog
    You cannot wash away blood with blood
  31. Actual MacOS Screenshot for Comparison by johnrpenner · · Score: 3, Interesting

    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: http://salon.com/ent/feature/2002/03/02/shakespear 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.

  32. Excelleny, hinting == misapplication of an idea. by Performer+Guy · · Score: 3, Insightful

    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.