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

List:       koffice
Subject:    Re: KWord 1.3 Beta Kerning Problems
From:       David Faure <faure () kde ! org>
Date:       2003-12-03 14:42:55
[Download RAW message or body]

On Wednesday 03 December 2003 14:45, Dik Takken wrote:
> Does anyone have explanations for this behavior? 
Yes
> Is anyone working on this?
Not in the short term.

Sigh... here we go again...
(pasting an earlier answer)

----

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 :(

----

Most of this comes from the choice of using Qt's painter and font mechanisms in KOffice.
It wasn't designed for this...
If we used libXft2/libfreetype directly we could get this to work, but that means
changing a lot of things.

There are two approaches under way to solve this: Lars tells me he is working
on fixing this in Qt 4 (new richtext engine and new font engine). Other KOffice
developers have started a kpainter library which reimplements text painting,
as an attempt to solve this. The issue is whether we'll lose much by going that
way (in particular all the support for RTL, Asian, Hindi and other complex text
that Qt supports).
Personally I'm rather going for the "let's wait to see what Qt 4 offers us" route,
given how many other things need to be done meanwhile anyway (in particular
the file format change). But as usual, the one who codes decides, and if the
kpainter people get it to work, I'll use that instead :)

-- 
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]