Welcome to the KDE Community Forums, the official forum board for KDE.
You are currently viewing the forums as an unregistered user. Registration allows you to post and discuss topics, receive private messages, vote on ideas, subscribe to topics and many such great features. Registration is a simple process and completely free. So register now and be a part of the community!
You are currently viewing the forums as an unregistered user. Registration allows you to post and discuss topics, receive private messages, vote on ideas, subscribe to topics and many such great features. Registration is a simple process and completely free. So register now and be a part of the community!
Is it me or is KWord's font rendering really awful?
21 posts • Page 3 of 3
• 1, 2, 3
Re: Is it me or is KWord's font rendering really awful?
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.
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.
Madman, proud to be a member of KDE forums since 2008-Oct.
21 posts • Page 3 of 3 • 1, 2, 3
Who is online
Users browsing this forum: No registered users and 3 guests

Search
FAQ
Policy
KDE.org
KDE.news
Planet KDE
More 
Kubuntu