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."
Breaks out in song... (Score:3, Funny)
I can see all webpages, in my way...
ClearType? (Score:4, Informative)
Re:ClearType? (Score:3, Informative)
Re:ClearType? (Score:2)
Re:ClearType? (Score:5, Informative)
Xft and fontconfig (Score:4, Informative)
XFree86 4 supports sub-pixel anti-aliasing (aka ClearType). You just need to put match edit rgba=rgb; in XftConfig.
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.
Re:Linux/X86 configuration standard needed bad (Score:3, Interesting)
<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>
Re:Linux/X86 configuration standard needed bad (Score:2)
Re:Linux/X86 configuration standard needed bad (Score:4, Informative)
It could have taken you one Google search for "xfree86 subpixel rendering" to find this [jmason.org] link!
-adnans
Re:Linux/X86 configuration standard needed bad (Score:2)
You know, I think I could enable subpixel rendering *faster* on Linux. On Windows, I would need to *find* the menu where windows hides this option. If you've experienced XP you'll know that this might not be as easy as it sounds. I'm sure I'll be pestered along the way by so called warnings about "damage" to my computer if I enter such and such a directory
And once the XftConfig langugage is replaced by a more structured XML DTD (soon) it will be much easier to concoct a GUI which would supposedly make activating/deactiving these features easier.
-adnans
Bring the holly grail: the GUI! (Score:2)
Yeah, GUIs are very intuitive and easy to use.
Re:Linux/X86 configuration standard needed bad (Score:2)
Ah, how intuitive... how many hours of reading manpages, HOWTOs and FAQs did it take to figure that one out?
Goddammit. This is what I really hate in Linux. You have to read tons of obsolete and badly written documentation until you can turn on something as trivial as sub-pixel rendering.
Actually, whenever I want to find out about something, I usually hit the newsgroups [google.com] to do a search. Usually I find what I need in about fifteen minutes or so. That's what I love about Linux: the community is always eager to help each other out by writing about their experiences. You don't find the same spirit of community in Windows...
Unless you enjoy tweaking your computer for hours and hours instead of getting something productive done at work, the current state of affairs is just unacceptable.
You said it, not me: if you enjoy tweaking your machine, you can do it for hours - but you don't have to. If you just want to do productive work, go ahead! In most modern distros (Mandrake in particular) the hardware detect and system setup is automatic...I don't know about sub-pixel AA for laptops, though...it might be good if someone actually made a distro just for laptops, as these usually seem more temperamental than desktops (and not only with Linux: installing Windows on some laptops can be quite complicated...)
Re:Now THAT's intuitive!!! (Score:2)
Likely no more friggin configuration files than Windows has friggin hives and friggin entries in it's friggin registry.
Bleah.
Re:ClearType? (Score:4, Informative)
--Ben
Re:Steve Gibson debunks M$'s "innovation" (Score:3, Insightful)
Yeah, but Gibson is also an ass who doesn't seem to know the difference between scientific method and guesswork.
MS research [microsoft.com] 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
Re:Steve Gibson debunks M$'s "innovation" (Score:2, Funny)
Re:Steve Gibson debunks M$'s "innovation" (Score:3, Interesting)
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
good, but not quite excellent.. (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.
Re:good, but not quite excellent.. (Score:2, Insightful)
Re:good, but not quite excellent.. (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).
Re:good, but not quite excellent.. (Score:2, Insightful)
My god, no wonder new exploits are constantly being found in Windows and IE.
Mike.
(-1, Offtopic)
Re:good, but not quite excellent.. (Score:2)
The real Microsoft Corporation is user number one. All others are imposters.
--saint
that's something completely different (Score:5, Insightful)
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.
Re:that's something completely different (Score:2, Funny)
You don't always have to throw hardware at a problem to solve it, that's MCSE thinking!
Re:that's something completely different (Score:2)
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.
-Erik
ClearType/XFree comparison (Score:2)
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.
-Erik
Re:ClearType/XFree comparison (Score:2, Informative)
Re:that's something completely different (Score:2)
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"
Re:that's something completely different (Score:2)
-Erik
Re:that's something completely different, -1 cluel (Score:2, Insightful)
Uh, actually virtually all CRTs are analog too. (Old CGA displays don't really matter much these days, though...) Or did you think the signal coming out of that 15-pin d-sub VGA connector was digital? Surprise, it isn't. Not to mention that some of the electrons meant to bombard phosphorescent element n tends to go astray a bit and bleed into adjascent phosphorescent elements. The results of this can be seen quite dramatically on low-quality CRTs at high resolutions.
In other words, paper is really no less digital than a CRT is. Just as a 640x480 image looks kinda blocky taking up your whole CRT, it looks just as blocky taking up a whole sheet of paper. It's paper's virtue of being able to handle insanely high resolutions that makes it suitable for "displaying" really clear graphics and text. I can't think of a single reason that a CRT oughtn't be able to do the same one day. Anti-aliasing is simply a stop-gap technology until that day arrives, IMHO.
Personally, if I had the option, I'd go for a 150 DPI (or better, actually 300 DPI would make me happy) display over something that only does, say, 1280x1024 with antialiasing. I'd much rather talk about picas and points than pixels. Pixels suck; they're the cause of too much geek envy. (Admit it! When you were still stuck with an 800x600 display you were drooling when your rich friend upgraded to a 20" display that could do a whopping 1600x1200.)
Re:that's something completely different, -1 cluel (Score:4, Insightful)
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.
Comment removed (Score:5, Informative)
Re: (Score:2, Interesting)
Re:Above is now a Complete Mirror (Score:2, Informative)
This is not only a problem with Netscape. The HTML code of the page is broken: there is a <table> tag at the beginning of the page and it is never closed. The table structure is incorrect anyway, because the <table> tag is immediately followed by <td> without a <tr>. The same problem occurs for a <center> tag and a <font> tag that are never closed (besides, the <font> tag occurs just before a block-level <h2> tag, so it should have no effect). Also, all color specifications are incorrect: missing quotes, missing "#" sign before the hex values.
MrP- [slashdot.org], if you are mirroring this slashdotted page, it would be a public service to fix the most obvious errors so that the mirrored page can be viewed by most browsers and passes at least some minimal HTML validation tests. The easiest way to fix the problem would be to remove the offending tags (2nd, 3rd and 4th line in the original page).
I highly recommend checking the page with HTML Tidy [sourceforge.net] or with the W3C validator [w3.org].
Re: Shitty browser (Score:4, Informative)
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...
just the hinter (Score:5, Informative)
Changing two lines of code is "hacking through"? (Score:3, Insightful)
How does changing two lines of code merit a frontpage story on slashdot?
Re:Do I detect a hint of jealousy? (Score:2, Insightful)
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.
Re:Changing two lines of code is "hacking through" (Score:2, Interesting)
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?".
Re:Changing two lines of code is "hacking through" (Score:2)
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.
--
Evan
Bill for Font Renerding Improvements (Score:5, Funny)
Breakdown:
Changing 2 lines of code = $1
Knowing which 2 lines =$9,999
This is often referred to as analysis (Score:2, Insightful)
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.
Re:Changing two lines of code is "hacking through" (Score:3, Funny)
I predict the next great hack frontpage story to be "Linux in one really huge line of Perl".
J
mine looks better (Score:3, Interesting)
all you have to do is add one line to your XftConfig
here is a howto:
http://jmason.org/howto/subpixel.html
Why is font rendering in X so bad? (Score:5, Interesting)
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?
Re:Why is font rendering in X so bad? (Score:3, Informative)
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.
Re:Why is font rendering in X so bad? (Score:4, Insightful)
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.
Re:Why is font rendering in X so bad? (Score:2, Informative)
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).
-Bruce
Greetings. (Score:5, Informative)
Here's another mirror [geocities.com]. 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
erm... why is hinting enabled then? (Score:4, Insightful)
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)
Re:AA text fuzzy? (Score:2)
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.
Re:AA text fuzzy? (Score:3, Informative)
--Ben
Re:AA text fuzzy? (Score:2)
--
Evan
Re:AA text fuzzy? (Score:2, Interesting)
Re:AA text fuzzy? (Score:2)
Re:AA text fuzzy? (Score:2)
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!)
-Erik
Re:AA text fuzzy? (Score:2)
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.
Re:AA text fuzzy? (Score:2)
Matt
Re:AA text fuzzy? (Score:2)
At work I have two monitors on my desk, both 21" Sonys. The one on the left runs at 1280x1024. The one on the right runs at 2048x1556 (I think). When I read PDFs, I open Acrobat full-screen on the right display, with AA turned on. Sitting about two feet away from the screen, as I usually do, the PDF is then almost indistinguishable from the printed page.
Medium-high resolution (> 120 dots per inch) with decent AA is a powerful combination.
Font antialiasing is a crutch (Score:4, Funny)
Re:Anti-aliasing is here to stay. (Score:3)
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:
Kinda sorta bloatware (Score:3, Insightful)
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.
Re:Kinda sorta bloatware (Score:2)
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.
TWW
Re:Kinda sorta bloatware (Score:2)
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
;-)
Font rendering in the X server (Score:5, Interesting)
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 (Score:4, Informative)
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.
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
Re:Font rendering in the X server (Score:5, Insightful)
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:
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).
Re:Font rendering in the X server (Score:3, Interesting)
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?
Re:Font rendering in the X server (Score:3, Informative)
Re:Font rendering in the X server (Score:2)
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
Re:Font rendering in the X server (Score:2)
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).
Compared to Mac OS X font smoothing (Score:5, Interesting)
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.
Plain XFT looks better (Score:2, Informative)
on my LCD screen right now, but the 'after' images
look much worse than the regular XFT rendering to
me.
The truth (Score:5, Interesting)
Fact 1: Hinting [microsoft.com] improves font legibility at smaller sizes.
Fact 2: Freetype doesn't interpret [sourceforge.net] the bytecodes in the fonts that are needed for proper hinting because of patents [delphion.com] detained [delphion.com] by Apple [delphion.com].
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 [linuxquebec.com] for Mandrake 8.1 [linuxquebec.com] and Redhat 7.2 [linuxquebec.com] of the Freetype library with the patented bytecode interpreter enabled.
Re:The truth (Score:2)
My distribution happens to do that by default
Hard to read (Score:2)
What does Microsoft want us to obsess over today? (Score:3, Interesting)
Hmm.. Matter of opinion.. (Score:2)
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..
A note on hinting and freetype... (Score:2)
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.
http://www.linuxquebec.com/~nomis80/ 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?
Nice, but still not quite right... (Score:2)
Gamma curves and antialiasing (Score:4, Insightful)
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.
Re:Gamma curves and antialiasing (Score:3, Informative)
V = B < .04045 ? v/12.92 : pow((v+.055)/1.055, 2.4)
blurry text (Score:3, Insightful)
Ah, so blurry text is an "aesthetic result"?
"Anti-aliasing" just means blurring [joelonsoftware.com], and is in general not a good thing. And this particular hack turns off hinting, to make it every blurrier.
Like headaches? Install this.
Actual MacOS Screenshot for Comparison (Score:3, Interesting)
Excelleny, hinting == misapplication of an idea. (Score:3, Insightful)
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.
Re:Ok, this is excellent (Score:2, Offtopic)
It's basically the only window manager I've seen that does fine-grained window memory right.
Re:Excellent! (Score:2)
It turned out that I had just never edited my
Re:color me crazy (Score:2)
"Hmm
It doesn't hurt my eyes, and text generaly looks more "roundish"*** which is nice - I think. Maybe it isn't, not quite sure yet. Now, this text (the text I'm typing right now) looks "skinny"* compared to the other text, as if it's only getting a double vertical AA** treatment.
Antialiased text (and other things) in theory is nice, because it's more "true to nature" (if there is such a thing in computing) - when was the last time you looked at bubble and thought "nah, those edges are jagged"? I thought so. On the other hand, I have from time to time caught myself looking out the window on say a sunrise and thinking "damn. They sure are using some cool effects."
I think another poster hit the nail [slashdot.org]. In essence he's saying that the people who make the AA algorithms are aparently more interested in making them "mathematically correct" than visually pleasing. Having stared at Microsofts ClearType for almost 15 minutes now, I tend to agree with both CmdrTaco and the aforementioned poster - somethings rotten in the state of text-AA.
*I'm Danish - can't quite think of a better word in English.
**I have no idea if that even makes sence outside of my own head
***Nope, can't even think of a better word in Danish.
Re:color me crazy (Score:2)
Now color me crazy, but since when has attaining similar aesthetic content to Windows been considered a good thing? It hurts my eyes just to look at it. I long for the good old days without those fancy anti-aliased fonts, although Mac OS X is quite pleasurable to use.
I didn't like the anti aliasing ("smooth edges of screen fonts") in Windows 2000 and didn't use it for a long time. Then it somehow got turned on, and when I noticed I decided to give it a chance. After a few days, I got used to it, and everything really does look better now. I stopped using Linux as a desktop, fonts being a big reason, so I don't know how well X does fonts with this (imho the screenshots are horrible on the eyes), but I suggest giving it a try for a few days and see if you end up liking it better.Re:My AA issue (Score:2, Informative)
All you need to do after apt-getting the packages is install a bunch of truetype fonts, then add the line 'export LD_PRELOAD=/usr/lib/libgdkxft.so' to your ~/.xession or some other appropriate location:
I had some issues getting it all working, but that was mostly user error. (I'd been playing with xfstt shortly before trying gdkxft and they seemed to interfere with each other)
A good howto on setting it up is here [jmason.org]
It makes mozilla look really pretty =)
Disabling hinting is NOT the way to go (Score:4, Insightful)
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.
Regardless... (Score:2)
The incredible quantity of design that went into X still produces an end result which causes the uninitiated to say "it's way too complex, and it just plain sucks."
Of course, then we explain that it doesn't suck, and that it's based on a perfectly sound architecture, and that it's really a work of beauty.
None of that changes the fact that it sucks.
The fonts look better with this (ugly) hack. Much, much better. This is the Sistine Chapel of two-line hacks.
--grendel drago
Re:Disabling hinting is NOT the way to go (Score:2)
Re:Disabling hinting is NOT the way to go (Score:3, Informative)
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.
Re:Disabling hinting is NOT the way to go (Score:3, Informative)
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.
Re:KDE Myths (Score:2)
Ikons will be in 3.0. Crystal-icons will be in 3.1. Check out the screenshot from lates KDE Kernel Cousin: http://kt.zork.net/kde/kde20020301_34.html )
Get rid of /. Ads (Score:2)
Re:Every time i look at a Anti-aliased screenshot. (Score:3, Insightful)
The two are related, the text looks blurred because it is, that's what AA does - it smooths (or smears) the edge of the glyphs in order to make the "jaggies" less obvious. Until you get used to it your brain can interpret this as the characters being out of focus and sends all sorts of trial adjustments to the eye to try to bring it into focus, which it can never do as the characters really look like that. Eventually your eye becomes tired from all these micro adjustments.
If you fiddle with your XfConfig file you can tell X not to AA above or below certain sizes so you might be able to get a better effect that suits you. On the other hand, if your monitor is good enough and you only use fonts designed for screen useage just turn AA off!
TWW
Don't you mean... (Score:3, Funny)