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

List:       koffice-devel
Subject:    Re: Simple KWord patch for frames extending beyond the page
From:       Michael Fair <michael () daclubhouse ! net>
Date:       2003-10-15 23:05:06
[Download RAW message or body]

On Wednesday 15 October 2003 12:50 pm, David Faure wrote:
> On Wednesday 15 October 2003 21:31, Michael Fair wrote:
> > This patch maps the topLeft point same as the original, but instead of
> > mapping the bottomRight directly, it subtracts the bottomRight from the
> > topLeft to get the width/height, maps that width/height as a point into
> > the view coordinates, and then adds the result to the mapped topLeft
> > point.
>
> Passing relative coordinates to normalToView() has rather undefined
> behavior. 

Well at the core level the algorithm uses the response from the mapping to me 
"How many units in View Space are this many units in Normal Space".  That is 
what viewToNormal actually means as long as the View Space starts at 0,0 
which as far I have been able to discern, it does.

I'm not really asking it to map a relative coordinate so much as I am asking 
how many units in view space is this "distance".  The result is the number of 
units in the view space the width/height distances are from normal space.

Having done this in other mapping systems I can say that it works quite well.

The only real concerns are if your view space coordinates don't have the same 
growth as the normal space coordinates (for instance, they both have to 
follow linear growth, or they both have follow the same logorithmic growth).
In this case both coordinate systems are linear and the function always 
returns the correct result so long as the frame height <= the page height 
(and I know how to fix that too).

Whatever the case, the default implementation in KWViewMode of just mapping 
the two points and assuming the result is still a rectangle can be easily 
revised by the patch to be correct in more cases then it is presently.

As long as you can't zoom page 2 without also zooming page 1, or vice versa, 
creating a situation where some given distance, returns a different result 
depending on what page it is, this patch will do the right thing.

> If your frame is actually higher than the page height, you should
> see strange result (the preview viewmode moving that point to the 2nd
> page).

If your frame is higher than your page height then it starts on the previous 
page and the patch "Does the Right Thing".  If you think your frame is on 
page 2, but the top of it is "higher" than that, then the frame is actually 
on page 1 by definition of the coordinate systems.  If you are saying that 
which page a frame is on should be determined by the bottom of the frame and 
not the top of the frame that is something different but just creates the 
inverse problem (for which I use the inverse algorithm).  If I understood the 
suggested algorithm of moving a frame to the next page because it "spans a 
page break" then it would always render every frame that is taller the page 
layout height on top on the last page.  Also, why not just move every page 
that spans a page up to the previous page instead of down to the next have 
frmaes larger than a page end up on page 1 instead?  The point being that a 
page that spans a page break is an error and needs to be fixed by the human 
unless a rather complex algorithm of moving and resizing can be determined.

This patch will render the above mentioned frame whose top is on page 1 as 
starting on page 1, and will draw it extending down past the bottom of page 
1.  Which as best as I can see is really the correct behavior to give the end 
user vidual feedback that something is wrong.  This is of course only 
temporary until it's decided that the frame should actually be broken into 
multiple frames and span multiple pages in which case the code needs to 
support the idea that a single frame in document space, when being 
transformed to view space, might return a frameset instead.  
Another solution would be that upon creating a frame that is larger than a 
page something is done to fix it up at creation time.  I don't think fixing 
it at render time is the right place to "modify" the frame.

Try the patch out, I think you'll be suprised how robust the algorithm and 
underlying principles are (I know I always am).

NOTE: All hell breaks loose if it is more than 1 full page higher than page 1 
(aka goes beyond page 0 and into page -1).  But that's hardly limited to this 
patch.  And even in that case, as long as the frame height is still shorter 
than the page layout height this patch will keep that frame in the shape of 
the original rectangle and I am fixing the page height limitation.)


> KWViewModePreview should simply reimplement QRect normalToView( const QRect
> & nRect ) (make it virtual) and do the right thing there.


I'll work on this but until it's decided that frames can cross page boundaries 
and the behavior is well defined, and there is a commitment that all the 
other supporting will work get done I don't have a good vision of what the 
right thing to do is much beyond the patch I've submited.

The only improvement I was looking at was not assume the frame was shorter 
than the page.  To keep the same "Just extend past the bottom of the page" 
rendering, the alogirthm is pretty simple.  

Here's the psudocode to get the new frame height:
while (bottomY > pageHeight) { 
    nHeight += normalToView( pageHeight );
    bottomY -= pageHeight;
}
nHeight += normalToView( bottomY );

This then gets added to the topLeft view point as the Y component.
This algorithm will work for both "Page Mode" and "Preview Mode".


Are you saying that you want to do the work now support a single frame 
spanning multiple pages?  That is a much more involved patch that I don't 
even feel qualified to write at the moment.  I can write the above 
optimization to protect against frames being taller than page layouts and 
submit that to you.  This patch has been simply intended to be a better 
version of the alrgorithm that's currently there and it does that job well.

Is there something different you want me to write?
I don't see what the right thing is different than what I've already proposed.

-- Michael --

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