[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: Pretty bad display of Verdana font in KWord
From:       David Faure <faure () kde ! org>
Date:       2004-10-07 15:09:51
Message-ID: 200410071709.54503.faure () kde ! org
[Download RAW message or body]

On Wednesday 06 October 2004 19:24, Matej Cepl wrote:
> Hi,
> 
> can anybody explain me why KWord 1.3.2 on Debian/sarge (with KDE
> 3.2.2 and Qt 3.3.3) has so lousy display of Verdana fonts? I
> would love to work with KWord (to make some good bugfixes for
> further development :-), but display of the text (View/Text
> Mode) is so poor that I have hard time to survive it (see
> example on http://www.ceplovi.cz/matej/tmp/kword.png). Can
> anybody help me to explain what might be the problem? Needless
> to say that display of the very same fonts in other applications
> (Konqueror, KNode, KMail) is pretty OK.

The famous WYSIWYG problem.
Is that at 100% zoom? If not, it should look better at 100% zoom.
Otherwise, well, the problem is that the font isn't completely proportional,
so the expected size doesn't match the actual glyph size (usually due to hinting).
It might work better with another font.

===

OK, you asked for an explanation, here's the long version that I wrote
some time ago and kept around for this kind of question:

Why WYSIWYG? Because any DTP or presentation software needs the text
to remain at the same place when zooming and when printing (and when
doing the presentation full-screen, which amounts to zooming).
Only latex-like word-processor doesn't really need WYSIWYG, and can lay out the
text differently at different zoom levels, as koffice-1.1.1 did. But this doesn't apply
to neither KWord nor KPresenter, since KWord has a DTP orientation too, and
text must fit in the frames that were made for it at a certain zoom level, etc.
Well, that was just to mention that "no wysiwyg" isn't a solution, since some
people suggested that ;-)

How WYSIWYG? In theory it's very simple: instead of "let's see how I would paint this
text, the font metrics say I need 100 pixels, ok, we reserve 100 pixels then"
(i.e. the fontmetrics at the current zoom level dictate the layout),
WYSIWYG needs the opposite: we pre-calculate the text layout, in a
zoom-independant manner (usually at high resolution), and
then we try to paint the text, at the current zoom, so that it fits into
the pre-calculated metrics.
The only way to make that look good is to use a font with the correct size for the current zoom
(something like "painting at high resolution in a scaled painter" would give exact metrics
but would be very slow and quite awful (no correct AA etc.))
The problem is that fonts have integer pixel sizes, and thus are not 100% proportionnal
so in the end, the word being painted isn't as wide as it should, or is too wide.
So I compensate on spaces. They get bigger or smaller, so that the next word
starts at the desired position (i.e. the one calculated from the hi-res text layout).

The above didn't lead to good results with some fonts, so to at least get good
metrics in the usual case, we currently use the font metrics at 100% zoom and
multiply them by 20, instead of calculating the metrics at 2000% zoom (which
also required loading large fonts, slow when Xft isn't used).

So at least everything looks good at 100% zoom - but as soon as another zoom
is used, for _some_ fonts (those where the char metrics don't grow proportionnally
to the font size), things look awful. So much for WYSIWYG if users have to keep
using a 100% zoom :(

The current plan is to wait for Qt 4 - or more specifically to bug Lars to
implement WYSIWYG in Scribe (it's on his TODO list, but with a question mark
after it AFAIK).

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
____________________________________
koffice mailing list
koffice@mail.kde.org
To unsubscribe please visit:
https://mail.kde.org/mailman/listinfo/koffice
[prev in list] [next in list] [prev in thread] [next in thread]