For those who get the bug :
go to System settings > Appearance > Fonts.
Set Anti-aliasing to "Enabled".
Click the "Configure..." button and disable Hinting.
Here the fonts were awful, now the rendering is great.

For more information, read the blog comments here.

Setting hinting as "slightly" instead of full disabling it also helped here.

I think it's hard enough in a linux system to get perfect fonts at global system level and for gtk applications at the same time, but it is feasible after some headaches and weeks of investigation.

Now, if it is requested to decrease global quality level to sligthly increase font quality in Kword, which is a specific problem of Kword, it looks like something is wrong.

If the problem is specific to Kword, Kword should solve its own problem, sometimes called "feature".

=> Current situation at my side

This is my 3 cents.

Maybe the solution described here http://slangkamp.wordpress.com/2009/09/ ... rendering/ helps.

Try yourself the supposed "solution" to make your own opinion, without decreasing global system font quality.

The user will not look for "help" (to be proved), but for the solution to have perfect fonts, easy to read without effort.

From the above:
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.

KOffice 2.2 seems to be out, but the problem remains even in there. To me the problem with fonts is a show-stopper too - it's just so painful to work with this kind of appearance. Changing fonts hinting from medium to none did not change anything better, but made the overall fonts worse (as bad as are fonts in KOffice). Setting it to full did not change anything in KOffice fonts either.

So.. um.. is the final decision that Qt is to blame? And as Qt guys say Qt is not meant for that kind of text rendering, there's nothing to do about it?

Yes, thats the conclusion and yes you can do something about it by commenting (politely!) on the Qt bug tracker maybe with screenshots or somesuch.

Madman wrote:Ideally KWord should do what the Cairo backend for Poppler does and disable font hinting.[/i]

This is exactly what KWord does. And for calculating the width it works as Qt does turn off hinting for that. Unfortunately the hinting is somehow still applied on the actual rendering. Which I believe to be a bug somewhere in either Qt or what Qt uses. (would be interesting to hear if stuff looks better on KWord for Windows or Mac)

zander wrote:Yes, thats the conclusion and yes you can do something about it by commenting (politely!) on the Qt bug tracker maybe with screenshots or somesuch.

Interesting, how OSS developers have become very sensitive about politeness lately

Anyway, I don't know the details about the fonts stuff, so I don't think I'd be the best person to lead tracking down the bug in Qt. Isn't developers interested in this? I guess it's a very-very important issue for KOffice to be acceptable as a mainstream application.

"Interesting, how OSS developers have become very sensitive about politeness lately"

I can imagine that Thomas responds somewhat grumpy, since people still say it's KWord's fault, while Thomas already said multiple that it's Qt's fault, even with a link to the bug report.

I understand that it's fault of Qt, but well.. my logic says that if some function within a used library is not working properly, it needs to be worked around somehow. But if users need to wait for smth else to get the program production-ready anyway, it doesn't matter much

One year later, what is the progress on this font rendering bug which makes Koffice useless ?

We spend quite some time a the last meeting discussing the problem and searching for a solution. So far no solution was found.

Only workaround would be to use Cairo for rendering.

There is something I do not understand here (not too strange: it's easy to not understand something on an argument you do not know ): LyX, wich is a Qt app, shows text perfectly. I selected an otf font as "screen font" for viewing during edition and to some extend text looks nicer during edition than on final dvi output... (automatic ligatures included!)
Why LyX is able to show screen fonts perfectly while kword have problems even on print preview? Is LyX using some kind of "workaround"?