OSAlert reader David Chester writes: “I’ve posted a modified version of freetype with hardcoded hinting options. (There are new hinting options available in freetype CVS, but apparently they will remain unaccessable from outside the library, so it has to be hacked by hand for now.) Anyway, I think the main reason it’s nice to have a hardcoded libfreetype like this, is that you can have OpenOffice link against it, which improves the readablity of it’s screen fonts to my eyes, and makes OpenOffice finally usable. I have some explanation and comparison screenshots“.
Better Screen Fonts in OpenOffice Under Linux
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSAlert.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
This article is about KDE, KDE has supported AA fonts for over a year and since has never had problems with displaying fonts.
So, what was the purpose of this article?
Have you seen the AA fonts in KDE? They look awful on my machine. Just look at the two comparison screenshots (http://www.cs.mcgill.ca/~dchest/xfthack/oo-before.png and http://www.cs.mcgill.ca/~dchest/xfthack/oo-slight.png). Very impressive.
always looked fine in KDE even after comparing to the screenshots. Now I am an Gnome user but this is one thing that I have always loved in KDE (Yes, I run Garome so this is no longer a problem).
But in my experience, KDE is always ahead of Gnome.
As to the question, I imported my fonts from MS and made the all two line change to enable those fonts over 6 months again and in my opinion the fonts look better than his screen shots do
This topic is rather near and dear to my heart, given that I just got an Inspiron 8200 with its 133-dpi screen. Because the pixels are so tiny, font rendering quality becomes a huge issue. Currently, the Xft has rendering set up, the TrueType bytecode interpreter hints the glyps, then the TrueType renderer anti-aliases them, and then Xft applies sub-pixel filtering. The hinting process causes some problems. Hinting was designed for monochrome displays, and distorts the glyph outline to make character features fall on certain pixels. On an anti-aliased display, which can (to the user’s eye) display finer details of the glyph, this tends to distort the glyph’s true shape. On my screen, this results in certain diagonal features (like on the ‘z’ and ‘2’) dissapearing. It makes italic text look really bad as well.
Now, there are a few ways around this problem. You can do what Mac OS X does and ignore hints completely. To my eyes (and anyone else who isn’t blind) this looks terrible. Fonts become softly focused and the “color” of letters (the appearance that all parts of the letter have the same weight) becomes non-uniform. Letters that fall on a pixel boundry unevenly look grey (because the weight of the letter is distributed evenly over two pixels) while letters that fall evenly on a pixel boundry look nice and black. Since the exact end rendering of each glyph basically depends on the random chances of how the glyph coordinates line up with the pixel grid, you end up with poor “color” across lines, ie. the weight of the strokes across the line is inconsistant.
The second way around this (and the far superior way) is to do what Microsoft does and slight-hint the fonts. Thus, in general, stems (the long parts of letters, like the legs in the ‘m’) end up on pixel boundries so the weight of the letter is uniform. However, finer adjustments, like adjusting a serif are not done, so overall the glyph shape remains more true.
Overall, Microsoft’s method is absolutely incredible. On a high-resolution display, the extra “fuzziness” produced by the more judicious hinting can’t be seen because the pixels are so small. As a result, anti-aliased serifes and diagnols look very nice and correctly weighted, while stems generally stay dark on pixel boundries. Supposedly, the only changes to the bytecode interpreter that MS made was that it ignores certain instructions, in particular the DIVP instruction (delta-hinting) which is used for those finer adjustments. When you add that to the cleartype filtering and gamma correction, you end up with paper-quality text at only 133 dpi.
Emulating MS’s font rendering is going to be a chore. First, its not entirely clear exactly what hints Microsoft is ignoring. It seems that this Xft-slight hack does some of the required slight-hinting work, but I doubt its as complete as MS’s solution. It seems that FreeType is going in another direction, abandoning the bytecode interpreter entirely and putting the intelligence in the autohinter to slightly hint glyphs. In the latest CVS version of FreeType, the autohinted output does look quite good, to the point where it might be a subjective call of which one (autohinted or TT hinted) you prefer. Second, Microsoft gamma corrects its anti-aliasing, which is something currently being tested in FreeType CVS. Lastly, there is the Cleartype algorithm itself. IMHO, this is a matter of personal preference. The algorithm currently in Xft does look better in the sense that it displays less (actually no) color fringing. However, I tend to prefer Cleartype’s filter, which makes letter edges a little softer. In the end, the choice of filter could probably be made by the user, because the relavent code in Xft is tightly confined to a dozen or so lines in the glyph loading routine.
You’re kidding right? Compare the ‘v’ in those screenshots, or the spacing between h i j k l. It’s clearly clearer.
Question is, how do you fix the awful looking fonts that apps like Crossover Office & Xine use? Apps like these use one particular font and it’s the ugliest thing I’ve ever seen. Hell, it’s hardly even readable.
It’s good to see that David is still at it, and it’s good that Red Hat have also done everything they could to make their fonts usable in their next release. I’m sure once all distros have copied Red Hat’s behavior, it will not be too long until stray applications get converted one way or the other.
The whole Linux/Unix font rendering issue is a real mess. I think I have to start searching for a good beginner’s guide. It took me hours to get my TTFs usable in KDE, and I have still no idea how to enable AA in OpenOffice and MoZilla.
Hi, for those of you who don’t know me, I hate X. I hate Win32 about equally (the Win32 API is definately nastier than xlib and ilk). I’m a Quartz advocate, in case you’re wondering.
Well, anyway, I wanted to mention any window system that requires a de-uglification guide for fonts (http://www.tldp.org/HOWTO/mini/FDU/index.html) needs to like, crawl in a hole and die. That is all.
Yes, X’s fonts are ugly. But at this point most users don’t have a choice other than to deuglify X somehow. Quartz only works on Apple hardware and isn’t open, newer GUIs that run on Linux still aren’t usable yet.
What really needs to happen is for the X developers to spend more time making the X code base more modular. This way, features like better font handling can be done without so many hacks, and newer GUIs that may replace X can use the (relatively) excellent video driver support in X.
The reason fonts look terrible in the stock OO is because the copy of freetype it’s linked to has the bytecode interpreter disabled (because of that stupid Apple patent).
If you’ve got a freetype which isn’t crippled on your system, all you have to do is:
export LD_PRELOAD=/usr/lib/mynoncrippledfreetype
before running openoffice. See my screenshots
before:
http://www.btinternet.com/~philmes/oo-freetype/without.png
after:
http://www.btinternet.com/~philmes/oo-freetype/with.png
The reason fonts look terrible in the stock OO is because the copy of freetype it’s linked to has the bytecode interpreter disabled (because of that stupid Apple patent).
If you’ve got a freetype which isn’t crippled on your system, all you have to do is:
export LD_PRELOAD=/usr/lib/mynoncrippledfreetype
before running openoffice. See my screenshots
before:
http://www.btinternet.com/~philmes/oo-freetype/without.png
after:
http://www.btinternet.com/~philmes/oo-freetype/with.png
The article is about OpenOffice.org which in no way related to KDE.
Besides, I rather have XFT2 AA than QFonts AA
—-
Anonymous: always looked fine in KDE even after comparing to the screenshots. Now I am an Gnome user but this is one thing that I have always loved in KDE (Yes, I run Garome so this is no longer a problem).
I don’t know, but everyone but you here says there is a difference. The AA in the hacked up version of OOo is much better.
Rayiner Hashem: Emulating MS’s font rendering is going to be a chore.
If it isn’t patented, I would agree with you.
Eike Hein: and I have still no idea how to enable AA in OpenOffice and MoZilla.
Mozilla’s one is absolutely unreadable, you are better off WITHOUT AA on it
For OOo, phil has a guide there, and make sure you are living in some country like Iran, or pay Apple for the patent, or live in guilt, mwuahahahaha…..
> Besides, I rather have XFT2 AA than QFonts AA
With the MS fonts I can’t see any difference in the rendering quality between the old font anti-aliasing of Qt 3.0 and a new Qt 3.1 snapshot which already supports xft2 (font quality is great with both). But the new fontconfig stuff is helpful.
I’m just curious if qt 3.1 will be using xft2 and fontconfig (as I ask in the title). If anybody can answer, I’d be grateful,
thanks
“Now, there are a few ways around this problem. You can do what Mac OS X does and ignore hints completely. To my eyes (and anyone else who isn’t blind) this looks terrible. Fonts become softly focused and the “color” of letters (the appearance that all parts of the letter have the same weight) becomes non-uniform. Letters that fall on a pixel boundry unevenly look grey (because the weight of the letter is distributed evenly over two pixels) while letters that fall evenly on a pixel boundry look nice and black. Since the exact end rendering of each glyph basically depends on the random chances of how the glyph coordinates line up with the pixel grid, you end up with poor “color” across lines, ie. the weight of the strokes across the line is inconsistant. ”
Mac OS 10.2 supports the same sub-pixel rendering that Windows XP does, and it’s user adjustable. Personally I think Quartz rendered fonts look incredible on a flat panel monitor.
I’m just curious if qt 3.1 will be using xft2 and fontconfig (as I ask in the title). If anybody can answer, I’d be grateful
Yes, it can. There are patches for QT3.0.x as well (which are applied to the version of QT in RedHat 8), which you can get from the fontconfig website.
GTK2/Pango in CVS are also capable of using fc/xft2.
It may also be of interest that Bitstream are currently working on a Freetype plugin to improve compatibility with non truetype fonts.
Mozilla’s one is absolutely unreadable, you are better off WITHOUT AA on it
Mozillas built in Freetype antialiasing is godawful, yes. There are patches from Keith and Owen which add xft2/fc support though – this looks really damn fine (or they do on my large monitor at a really high resolution. YMMV at lower resolutions):
http://freespace.virgin.net/phil.mes/moz-xft2.png
I may be incorrect, but reading the linked article, and reading the comments, I can’t help but assume that a number of programs use their own xft libs. Now, it seems that both gnome and kde use the xfree xft lib, and that’s good. But why should mozilla and openoffice not use it? Is there a problem with the current arrangement? Is there any demand for them to use the system version?
It’s very unprofessional!
To Basclue: Where is the font deuglification guide for OS X? Oh wait…
To Anonymous: I just got back from using a brand new, wide screen, flat panel iMac with OS X 10.2. The fonts look terrible. Yes they’re sub-pixel anti-aliased, but they’re still unhinted. As a result, all the color consistancy problems are still there, the end result is just a little less blurry (and yes, that’s all subpixel rendering will do, make anti-aliased text just a bit sharper. Its a subtle effect, not a giant one). They don’t compare to the slightly borked rendering of Xft, much less to the near-perfect rendering of ClearType. The iMac flat-panel (hell, even the TFT in my Inspiron) just doesn’t have the resolution necessary to do away with hinting entirely. Once we get to 300dpi, maybe, but until then, you need some level of hinting.
Where is the font deuglification guide for OS X? Oh wait…
Oh wait indeed, it’s unnecessary.
Really, if you don’t like antialiasing, why don’t you just disable it? That’s what the preferences pane is for.
Mac OS X doesn’t have good anti-aliasing.
For examples of good anti-aliasing see:
http://www.microsoft.org/typography
http://www.adobe.com/products/acrobat/cooltype.html
http://ftp.freetype.org/freetype/unstable
Mac OS X doesn’t have good anti-aliasing.
OS X only has the best font handling I’ve ever seen in any operating system ever.
For examples of good anti-aliasing see:
http://www.microsoft.org/typography
404s, perhaps you meant microsoft.com, in which case everything presented to me is ugly as hell. And furthermore, it’s not antialiased.
http://www.adobe.com/products/acrobat/cooltype.html
Again, not antialiased. Perhaps you just dislike antialiasing?
http://ftp.freetype.org/freetype/unstable
Umm, thanks for pointing me to their FTP server. Well, having done work with FreeType before, I’ll say that I like what I’ve seen in FreeType 2, to the point that I’d consider it on par with OS X.
It seems like you like your jagged, pixelated letters. That’s fine for you… if you don’t want antialiasing in OS X you can turn it off you know. I’ll happily keep my antialiasing, because it makes all the text look beautiful.