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

List:       koffice-devel
Subject:    Some input on tables
From:       Elvis Stansvik <elvstone () gmail ! com>
Date:       2009-06-12 12:14:15
Message-ID: 751a4f870906120514n37489ef3h75f57152973dc5d9 () mail ! gmail ! com
[Download RAW message or body]

Thomas, all,

Since questions often tend to get misunderstood, this mail is instead
mostly a series of statements about my work. I'd like you to jump in
and react with "no no", "no, but..", "yes" and "yes, but.." responses
accordingly :)

- What I get "for free" from Qt -

Nothing is free in this world and I know that [1], but Qt will give me
QTextTable and its associated QTextTableCell along with their format
classes, which I can consider the "specification" for the layout and
drawing work I'll be doing. The format classes will have to be
extended, similar to how QTextListFormat is extended for lists, in
order to support ODF formatting properties not supported by Scribe.

Qt also gives me the serialization of these classes and format classes
into a QTextDocument (string of Unicode characters).

- What's ahead -

There are three big parts to this.

The first part is to actually lay out and draw the table according to
its properties and format. Qt's built-in support for laying out and
drawing QTextTable's is hidden away in its private class
QTextDocumentLayout (which shares ABC with kotext's own layout engine
KoTextDocumentLayout). Hence, this support is unavailable to me and
all layout and drawing of tables, their borders, paddings, margins,
cell spanning et.c. will have to be done from scratch, in the text
layout engine in Layout.cpp of the textshape. I should be able to find
quite some inspiration by looking at Qt code for this, particularly in
QTextDocumentLayoutPrivate::drawFrame() and
QTextDocumentLayout::drawTableCell() et.c.

The second part is to "nudge" the text layout engine into laying out
text blocks (and shapes) that are found to be inside table cells at
the correct position and within the right confinement. This should in
theory be possible by controlling the Layout::x(), Layout::y() and
Layout::width(), similar to e.g. how the
KoParagraphStyle::AutoTextIndent style is handled
(Layout::resolveTextIndent()), but with y position and width also
taken into consideration, in addition to x position.

The third part is of course loading and saving.

- Initial approach -

As Thomas suggested to me on IRC, best is probably to start working on
table layout tests in the textshape and making them pass, so this is
what I'm working on right now. I agree with this, as it will initially
not touch any loading code or any of the existing rudimentary table
support. I can just happily work away there and even commit to SVN and
make sure no regressions are introduced. For visual feedback/debugging
I can locally hack up some primitive loading and paste HTML tables
into KWord.

- A couple of technical questions -

 o I understand the x(), y() and width() control the positioning and
confinement of the layout engine, but can I expect any surprises here?
Is it law, or are there any places where the layout engine will not
obey these?

 o Given a QTextCursor, I can use QTextCursor::currentTable() to
determine if I'm inside a table, but I guess I shouldn't use this
method too liberally, as it does a parent frame traversal and
qobject_cast<QTextTable *>, and instead have state flag(s) within the
layout engine that I set/unset to track whether I'm inside or outside
table cells?

All feedback/corrections/suggestions are very much welcome. In the
meantime I'll keep working on a first basic layout test.

Regards,
Elvis

[1] Weird statement from a guy working on free software, but you get
what I mean ;)
_______________________________________________
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]