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

List:       koffice-devel
Subject:    Re: Tables in KWord?
From:       Karl-Heinz Zimmer <khz () kde ! org>
Date:       2008-03-17 9:14:53
Message-ID: 200803171014.55230 () postmaster ! bugcops ! org
[Download RAW message or body]

Am Montag 17 März 2008 09:12 schrieb Boudewijn Rempt:
> On Mon, 17 Mar 2008, Karl-Heinz Zimmer wrote:
> > What is the priority of "Find a good way to have tables in KWord"?
>
> I started a table shape earlier this year. For me, it's got some
> priority: I don't think I've ever seen a business document that
> doesn't have tables. The authors of the KWord 1.x table feature has
> helped me a lot discussing things.
>
> Right now, I'm stuck waiting for ODF text support to improve enough that
> I can make a couple of decisions:
>
> * Make it possible to have any shape as cell contents (so a
>   text cell will be a text shape)?
> * Use QTextTable as the basis for the table model, or not (I'm
>   veering towards the latter) 
> * Integrate the table shape as an embedded object in a text shape's
>   QTextDocument by:  
>   * using a Unicode text object (QChar::ObjectReplacementCharacter) 
>   * a QTextObject derived class (QTextTable is a QTextObject already) 
> * Make it possible for cells to  have different widths in differnt
>   rows (MS Word supports that, ODF doesn't)
> * Implement multi-page tables as linked shapes or as one multi-page
>   shape (I think the former, as that's what ordinary running text
>   seems to do).
>
> My plan of attack was to first make loading and saving loss-free: i.e, a
> complete roundtrip, and only then worry about display, and after display
> worry about editing. The big problem with 1.6 tables was that they were
> hard to edit because of the way every cell was a frame and that
> multi-page tables were very badly supported, so that's what I keep in
> mind when working on this.
>
> > Probably this needs brain work of two or three people discussing,
> > and of course most of us have very few time left (if at all) so
> > what is the future of tables' design?
> > Is discussion going on, input or contribution wanted/needed?
>
> Inge was going to help with the implementation of loading/saving, and I
> sure could use help with implementing display/editing. First we need to
> arrive at a clear idea of the answers to the problems I enumerated
> above. And, of course, I'd be quite happy to delegate lots of work to
> other people, I'm pretty well loaded up on work already.

I fully agree that support multiple pages is important: In some business 
documents even a single CELL can spread more than two pages and it would 
be nice if KWord could do that too, adjusting when data is added/removed.

Tonight I will have a look at the current kword source on the hobby PC to 
get an idea of it ...

Also while OOo Writer does not make that easy, it actually is possible to 
have different cell widths: You select two neighboring cells within the 
same row, then say "Merge Cells", then say "Split Cells: Horizontally" and 
there are your cells having their freely adjustable internal width.

You can even say "Insert/Table" while editing a table cell's content and 
you will get a nicely embedded table inside your cell, but at least the 
embedded table will be a paragraph of its own.

Also the type of a normal cell's content can be mixed, e.g. having text and 
images together in one cell is not uncommon in OOo Writer: Images do /not/ 
necessarily cause a new paragraph, but they can be anchored in all of the 
normal ways offered by Writer (e.g. "As Character").

Cheers,
Karl-Heinz
-- 
Karl-Heinz Zimmer, Föhren, Germany  <mailto:khz@kde.org>

"For every complex problem there is an answer that is clear, simple,
                                                          and wrong."
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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