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

List:       koffice-devel
Subject:    Tables for KWord, next iteration
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2008-05-15 21:26:22
Message-ID: 200805152326.22678.mail () dipe ! org
[Download RAW message or body]

Tables are still a huge thing and one that affects a lot of our current code 
what means, it would be nice to continue the discusions we had so far [1].

Possibilities;

1. TableShape
I guess this is really the worst thing to go since it would mean we would need 
one textshape per cell and that sounds like a bad idea specially for large 
tables. Also we would need with various other things like splitting the shape 
if it's larger then a page and we would need to deal with nested shapes. Also 
we would probably need to use the same logic for columns then.

2. Extend the current layout code.
Those code-base is a rather huge mess imho and tables+nested tables would turn 
it into a code-monster. The idea would be to fork here the (private and not 
accessible) logic scribe's layout has for tables and extend our layouter with 
it.

3. Throw away our layouter and use Qt's one.
What would be for sure the most logical and easy way to go. But the problem 
is, that those layout-code can't be extended and therefore we would be bound 
to what scribe's layouter allow us to do. A bit problem if it comes to shapes 
since we have custom code in there to deal with them to allow to e.g. run 
text through/around them.

Hints, ideas, etc.? (nested tables is btw a *must have* - so, flat tables like 
we had in 1.6.x is imho not an alternate and we should consider this from the 
beginning).

[1]
http://lists.kde.org/?l=koffice-devel&m=120574617208477&w=2
http://lists.kde.org/?l=koffice-devel&m=120582471310900&w=2
_______________________________________________
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]