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

List:       koffice-devel
Subject:    Re: Tables for KWord, next iteration
From:       Thomas Zander <zander () kde ! org>
Date:       2008-05-16 6:03:44
Message-ID: 200805160803.44957.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 15. May 2008 23:26:22 Sebastian Sauer wrote:
> 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

I again will put on the table to possibility to ship 2.0 without tables. 
Certainly at this time its better to ship something then to wait for this 
work to be stable.

> 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.

I'll try not to take any offense ;)

> 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.

Traditionally TT would just expose some API for this purpose.
I didn't request such a thing since the scribe tables is heavily based on html 
behavior. With things like percentage based sizes and corner cases where the 
user gave 5 rows a total of 140% width...

So, while I'm sure it would be a good start point there are some problems;
1) we can't legally fork due to us using LGPL
2) the layouting of tables in Qt is also giving me hairloss at times. Its just 
a really big bunch of code and lots of knowledge of that code is required to 
do this.  I'm still learning it.  I really don't expect anyone here to be 
able to do it in under a year.
And this is nothing against the Qt stuff; I was also the only one that 
understood the table code in KWord1.x.  Table layout is just plain hard.

> 3. Throw away our layouter and use Qt's one.
> What would be for sure the most logical and easy way to go. 

Logical? In what universe :P
I didn't spend a year writing that layouter without very good reason, you 
know :)
You do realize that scribe is already *very* pluggable and the only thing we 
are layouting is the sentences.  In KWord1.x we were layouting to the 
character (glyph, really) level. All that we now share with Qt (and in part 
even with Pango).
IMNSHO this is not an option :)

What I suggest is to keep the table *loading* exactly like it is in scribe. 
Read QTextTablePrivate::createTable (qt/src/gui/text/qtexttable.cpp). If you 
mirror that behavior you can finish the ODF loader after creating a 
tableStyle.

Which means that there is a QTextTable that is *mapped* onto a set of strings. 
Each string is a cell.  The cells are separated with the Unicode character 
BeginningOfFrame QChar(0xfdd0) and the table is closed with EndOfFrame 
QChar(0xfdd1).

So if your loader creates this then we can test it using the normal scribe 
layouter and we can reuse the html-loading/saving code from scribe to 
insert/read tables.

I don't think tables is a 2.0 thing to focus on. Yes its important, but 
releasing is more important. I probably won't write the layouting code before 
2.0 is out. If someone else wants to do the job I won't stop him (just get 
sad if it releases delayed).
-- 
Thomas Zander

["signature.asc" (application/pgp-signature)]

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