For quite some time I have been wondering what’s wrong with font rendering in KWord. I have seen KWord on other systems where the fonts rendering looked nice and sharp, but I couldn’t get the same look at my own system. The screenshot below shows how that looked.
The topic was discussed in the KDE forum and then in the KOffice IRC channel, where I finally got the right hint. The clue is changing the hinting style in the KDE systemsettings. This requires a some experimentation to find out which mode works best.
For me the change from full hinting to no hinting brought a great improvement as you can see below. The font in menu and toolbar changes a bit too, but that doesn’t bother me that much.
Maybe it’s possible to get even better rendering by flipping some secret switches, but so far I’m quite happy with the result.
Sven's Blog 
September 29, 2009 at 2:31 am
I guess the problem is that you are using a font that does not contain hinting instructions. Then the auto-hinter tries to hint it and the result varies a lot but is generally not good (at all). You should try using a hinted font, such as DejaVu for instance, which should look good with full hinting (provided your distribution has activated the patented bytecode interpreter).
September 29, 2009 at 3:01 am
I’m far from being an expert here but fonts look that horrible for me too in KWord and I use medium hinting.
Anyway fonts on my display look significantly worse both without hinting and with full hinting, so disabling hinting for me certainly doesn’t sound like a solution, since all other applications look worse.
Since KWord is the actual office application here they should be the ones fixing the issue not end-users.
I also noticed they look horrible up to a zoom of around 400% when they start looking very nice – furthermore I tried getting same letter sizes with different fonts in different apps and they always looked better than in KWord.
IMHO KWord is doing something wrong and you should insist with the developers they get it fixed.
September 29, 2009 at 3:33 am
I use “slight” hinting as it increases the sharpness of the text without overly distorting it like full, or even medium, hinting does.
September 29, 2009 at 5:14 am
Just in case anyone else is looking for these like I had to:
Kmenu (start) button -> SystemSettings -> Appearence -> Fonts -> Use Anti Aliased (Enabled) -> Configure
September 29, 2009 at 8:14 am
This should not be considered a satisfactory solution. Disabling hinting entirely — while necessary for WYSIWYG editing — produces markedly worse rendering for almost anything else.
Hinting works (i.e, improves rendering quality) by aligning the stems of characters to the pixel grind — so a vertical line, such as those in an H, start and end on a pixel boundary. However, one of the problems with hinting is that it has the side-effect of changing the width of characters.
This means that while a character may claim in its metrics to be 1em wide when rendered with hinting it could end up as 0.8em (effectively). The extent of this depends on the hinting algorithm used and the DPI of the device. Higher DPI devices have more pixels in a given region, so less aggressive hinting can be used. At 300 DPI you can ignore hinting completely. For 10pt Times New Roman in Windows the error is around one letter for every 10. (So for every 10 letters you see on screen hinting will cause the width of the string to be somewhere between 9 and 11 ‘real’ letters; I call this drift.)
So, why is hinting unsuitable for WYSIWYG? Well, if the width of a line, hence location of a line break, depends on your screens DPI/zoom level then it is no longer as WYSIWYG, as it could turn out totally different when printed. Imagine zooming in on a document and finding the locations of line breaks changing!
Microsoft Word, solves this problem by inserting random space between letters/words to counteract the effects of hinting. This way it can still use hinted text and be a true WYSIWYG editor.
Abobe Acrobat (and most Poppler-based PDF viewers such as Evince) take a different approach. They use unhinted text — which due to the lack of hinting has no drift. In my experience the best results are obtained using slight hinting, — which hints in the y-direction but not in the x-direction — along with subpixel rendering. This still allows for accurate reproduction of the letter-forms, but with almost no drift.
Ideally KWord should do what the Cairo backend for Poppler does and disable font hinting.
September 29, 2009 at 11:12 am
There is a discussion on kde-devel about this:
http://lists.kde.org/?l=kde-devel&m=125419767822733&w=2
Apparently Okular has the problem too.
September 29, 2009 at 11:25 am
Okular is a different issue entirely. The reason rendering in Okular is substandard (compared to Evince, which also uses the Poppler rendering library) is because Okular uses the Splash backend of poppler. Splash is based off of the rendering code used by Xpdf. Evince uses the Cairo backend of poppler. The Cairo backend produces much higher quality output in most cases — especially with regards to text and line art. Splash does have better bitmap scaling, however.
The reason Okular uses the Splash backend is because the Qt (Arthur) backend is incomplete and there is not Qt-like interface to the Cairo backend.
September 29, 2009 at 3:26 pm
That was a very good explanation Freddie. There has been a great deal of confusion about this issue, and this is the best (as always the simplest one) explanation I have read.
Would you consider writing a blog post about this matter Freddie?. It would help a lot of people and maybe even developers understand this issue.
Anyway this situation is a pity, because we won’t be getting 300DPI displays any time soon. What can be done is to complete the Arthur backend for poppler and Kword can disable hinting (or as suggested, only enable it for the y-direction).
September 29, 2009 at 4:17 pm
Allowing Okular to use the Cairo backend would be more than satisfactory, IMO. My understanding is that this would require some changes to poppler, to what extent I am unsure. I think you’d have great trouble finding a modern Linux desktop Linux installation without a copy of Cairo installed — hence I don’t buy the dependency/political argument.
KWord does not have to disable hinting. Inserting or removing spacing will suffice, which as I said above is how Microsoft Word handles the situation. (Actually, it is slightly more complex than that, but the less spoken of Words text layout, the better.) The advantage is that the text has a similar look to that in dialogues/web browsers.
However, it is my opinion that the less we make use of hinting, the better. The whole idea of warping characters to pixel boundaries can be thought of as a hack to make up for the low DPI of commodity desktop hardware. It is possible to (almost) do away with hinting entirely. Take a look at OS X which obtains accurate high-quality rendering without the need for aggressive hinting. (Subpixel rendering technologies are used to increase the effective horizontal resolution of the screen.) In fact it is this lack of hinting which makes the zooming feature on the iPhone feasible — something that is just not possible with hinted text. (As zooming it would require you to redo the layout for the page/document.)
September 29, 2009 at 10:25 pm
@Freddie I simply hate subpixel hinting or rgb hinting it only works if the pixel is small enough. Allot of people complain about becoming very tired after a day of reading documents in mac.
now about kword, ideally it should be able to set the hinting style on the document preview page, I tend to think WYSIWYG is important there, but i really like my medium or full hinting on my day to day screen.
November 23, 2009 at 11:08 am
@Freddie You may be interested to learn that a Qt interface to the Cairo backend is already available. I wrote the code myself, but unfortunately it was rejected by the Poppler project on the grounds that introducing a dependency on Cairo to a Qt application would be controversial (even if it was a compile-time optional dependency).
As a result, I now maintain the patchset separately. You can find it here: http://github.com/giddie/poppler-qt4-cairo-backend.
December 27, 2009 at 9:24 pm
@miquel I don’t blog; however I have, over the past few months, written up most all I know about font rasterisation and free software on a dedicated page: http://freddie.witherden.org/pages/font-rasterisation/ (Any and all feedback welcome!)
January 31, 2010 at 11:56 pm
@Freddie – The stuff of textbooks (http://freddie.witherden.org/pages/font-rasterisation/) – Thanks for sharing the illustrative knowledge !!