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

List:       koffice-devel
Subject:    Re: Help needed with KSpread zoom
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-06-12 6:36:10
[Download RAW message or body]

Am Dienstag, 11. Juni 2002 01:00 schrieb John Dailey:
> This is definitely the problem here.  Try setting two adjacent cells with a
> background color and you can see white between them in a high zoom
> environment.  The rounding error shows up in both directions -- when zoomed
> in the cell isn't completely cleared, and when zoomed out the cell clears
> out too much, thus erasing neighboring cell's grid border.

Yes this is the sympthom, but after digging deep into the source and trying to 
avoid the empty "pixels", I couldn't find a rounding issue here. I rather 
assume, that the scaling with the worldmatrix adds/removes pixels and the 
paintBackground function doesn't know about them. I didn't find a way to 
handle them. Even no "hack" :-/

> It seems like it is going to be necessary to scale the canvas and paint the
> cells in zoomed coordinates.

Yes

> It doesn't matter so much if we use the
> doubles or not, because the painting functions take integers anyway.  

No, with the current QMatrix it doesn't matter (I tested it), but if we do it 
manually, then it does (like at the scrollbars).

> It's not that we're performing any operations on the integers that give a
> rounding error.

Yes we do some operations, which may give rounding errors.
1. width() and height() must always consider where the next cell starts, like 
I described in my example first.
2, We do at several places 
for (col = first; col<= last; col++)
   mywidth += column->width()
paint(mywidth, y, width,y);
For these cases mywidth must be double and we need to use dblWidth().

But I need to test it first with a manual zoom operation, maybe I just see it 
too complicated.

> The rounding error is happening when the QPainter is
> scaling for the zoom. The difference between this and the zoom work done on
> the column/row label bars is that those were painted to account for the
> zoom manually.  The main canvas in the code right now is painted in the
> same coordinates no matter what the zoom.
>
> This definitely looks like an intrusive change.
>
> Unfortunately I'm not going to have time to complete this during the week
> and I will be travelling over the weekend.  Would this help you get jump
> started on it (Norbert or Phillip)?

Yes, I will have time on weekend and will try to do a lot. 
What I will do first is comment out the scaling with QMatrix and then go step 
by step through the code and add the zoom again manually.
I think, children (like chart) I will leave out in the first round, as they 
seem to be more complicated.

> I'll see what I can dig up on the embedding zoom problem tomorrow. 
> Hopefully that will be simpler to fix!

Fine.

Let's try to fix it.

Again my hope, that David or Laurent can say something about how KPresenter 
and KWord is handling zoom, as when we start to reprogramming, I don't like 
to change everything and then see that it should have been done differently.

I tried several looks at KP and KW, but there handling of zoom is somehow 
complicated. Some words may help here. They seem to have different zoom 
values for x any y direction.

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