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

List:       koffice-devel
Subject:    Re: Confused by KWord
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-03-11 18:30:47
[Download RAW message or body]

On Monday 11 March 2002 12:07, Simon MacMullen wrote:
> I've been trying to get my KOffice thumbnail thing working properly (mostly
> concentrating on KWord), but I'm getting more and more confused. The thing
> I'm getting confused by is the semantics of KoDocument::paintContent().
> 
> I initially assumed that paintContent() was supposed to be free of side
> effects to the document, and would just effect the QPainter that was passed
> to it. But calling it with a zoom of anything other than 1.0 leads to the
> currently loaded document resizing to that zoom level (but the text point
> size does not change!) Looking at KwDocument::paintContent I see that the
> first thing it does is set m_zoom, and then call setResolution(), so this
> behaviour is unsurprising.

Yes, painting at a given zoom level requires to change the zoom everywhere,
because of pixel-based information being stored in the character class (KoTextStringChar).
I would have loved to do without it, to be able to have different views at different
zoom levels, but didn't find an easy way (we'd have to store much information
in the views, for every parag and even every char!)

> So is this a bug (in which case I can try to fix it myself, fail, and then
> watch David Faure fix it in 10 minutes), or is it meant to work like this? I
> wondered whether what I wanted was a KoView (assuming that's View as in
> Model-View-Controller) but KoView::paintEverything just tells the document
> to paint itself and we get the same effect.

You don't need a view to get the doc to paint itself, a view is for the user
to manipulate the document.

> I tried just calling paintContent() with a zoom of always 1.0, and scaling
> the resultant pixmap, but it would appear that when KWord is at a zoom of
> "100%", m_zoom is equal to 0.998723 (on my system anyway), so the screen
> display gets corrupted anyway.

Looks like the DPI setting. Try setting the zoom (passed to paintContent) to
QPaintDevice::y11AppDpiY() / 72.0

> So can someone (David?) tell me, is paintContent() supposed to be
> side-effect free?

In theory it is, but in practice it isn't.
This isn't usually a problem, except when multiple views show the same document.
In your case, I suppose you're trying to generate a picture of the doc for
the preview, while there's a normal view showing the doc? If you're writing
KWord-specific code (as opposed to KoDocument-only), you could do what is done
in KWord for generating e.g. the preview when creating a template. See
KWView::extraCreateTemplate, it uses frameset->drawContents(). Well, and
it sets the zoom before, and restores it after, which is what could be done
with paintContent too (except that it might slow down normal embedded documents :(.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]