KWord font rendering

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.

kwordfullhinting

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.

kwordnohinting

Maybe it’s possible to get even better rendering by flipping some secret switches, but so far I’m quite happy with the result.

About these ads

13 Responses to “KWord font rendering”

  1. Med Says:

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

  2. Radu Benea Says:

    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.

  3. Lucas Murray Says:

    I use “slight” hinting as it increases the sharpness of the text without overly distorting it like full, or even medium, hinting does.

  4. Bugsbane Says:

    Just in case anyone else is looking for these like I had to:

    Kmenu (start) button -> SystemSettings -> Appearence -> Fonts -> Use Anti Aliased (Enabled) -> Configure

  5. Freddie Says:

    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.

  6. slangkamp Says:

    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.

  7. Freddie Says:

    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.

  8. miquel Says:

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

  9. Freddie Says:

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

  10. nuno pinheiro Says:

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

  11. Paul Gideon Dann Says:

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

  12. Freddie Says:

    @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!)

  13. Just a lookin' Says:

    @Freddie – The stuff of textbooks (http://freddie.witherden.org/pages/font-rasterisation/) – Thanks for sharing the illustrative knowledge !!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Follow

Get every new post delivered to your Inbox.

%d bloggers like this: