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

List:       koffice-devel
Subject:    Re: KWord table problems
From:       David Faure <faure () kde ! org>
Date:       2004-07-16 9:13:24
Message-ID: 200407161113.24789.faure () kde ! org
[Download RAW message or body]

On Friday 16 July 2004 09:54, Nicolas Goutte wrote:
> However it is here that I have a few questions:
> - what is the difference between a "line" and a "row"?
I don't think there's a difference, afaics line is just a loop iterator.

> - why are new cell created, but the table have no repeated headers by default?
Hmm, where?
[Maybe this is in order to split the cell that is across pages? But I don't think so]

> Also there a few comments, in what I suppose is Dutch:
> - // voeg top in in rowPositions
> - // add header-rij toe. (en zet bool) TODO
That's from Thomas Zander, who should know better than to use Dutch in source files :(

> As from the code point of view, from what I know currently, the problem is 
> that the function is first removing the page top rows of the table and then 
> create new top rows. I think that such a code will always have border case 
> and it would perhaps be easier to have a loop making both:
> - if a row does not fit on the page, but it on the next.
> - if a change of page occurs but that there is still place for the row, the 
> page change should be removed.
> As this would be done smoothly row by row, it would avoid leaving page changes 
> were it should not.
I can't see what's fundamentally different with the current code, but well, it's
so difficult to read that any simplification/rewrite is certainly a good idea.

> Also for the loading of files, in the function KWTableFrameSet::loadCell there 
> is a comment:
> // TODO run the formatter over the text here
Ah that's probably from me. Yeah, setting the minFrameHeight to whatever the
import filter decided should be the height, seems like a pretty bad idea.
AFAICS This code only works when the table was created by KWord itself
(with the same font...)

> How would such a call look like?
Hmm, something like cell->layout()
But for this to work, the width of the cell has to be known, and I guess that's not
the case at that point. So it would seem better to set the minframeheight only
after 1) the columns have their final size (recalcCols I guess) 
and 2) the text of the cell was formatted.

I strongly suggest that you try non-inline tables first.
Multi-page inline tables are much more difficult to support, because you need
one "custom item" (the thing that behaves like a character in a paragraph although
it contains something else, like variables and inline frames etc.) per page.
(KWTableFrameSet::createAnchors).
So in addition to the bookkeeping that needs to be done for non-inline multipage
tables (the page breaks and the header rows) you also need to do some bookkeeping
on the custom items....

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