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

List:       koffice-devel
Subject:    Layout process of text, and sections
From:       "C. Boemann" <cbo () boemann ! dk>
Date:       2010-01-27 13:47:24
Message-ID: 201001271447.25083.cbo () boemann ! dk
[Download RAW message or body]

Hi

I'm trying to implement sections support in text shape.

A section is a number of blocks (paragraphs) all sharing the 
same left and right margins. A section can also specify that 
those blocks should be laid out in columns. This column layout is 
not like ordenary page columns. Page columns fill the entire 
page and fill up one full column at a time. Section colums take 
the available text and destribute it in the columns, so these 
columns will always have equal amount of text.

We also have tables, which was implemented last year. We all 
know what tables are, so no further description is necessary.

The trouble begins because you can have tables within tables 
within sections within tables within tables, and so forth.

In Qt this can be nicely represented. Qt already knows about 
tables, and has the concept of a frame which we can reuse to 
represent a section. Qt can have the tree structure of this so all 
is good here. In fact I've already implemented and commited 
sections on this level, complete with section styles.

The layout is where I'm having trouble. because of the tree like 
structure that is allowed the current flat traversal of text blocks 
makes us lose sight of the tree structure. The flat traversal was 
good in 2.0 days when all we had was text blocks. When we 
implemented tables in 2.1 the flat traversal showed some strain, 
but because we didn't promise sub-table support it was 
managable. Now with sections and sub sections etc this 
becomes unbearable.

Another feature (that we don't want to lose) that gives me 
problems is that the layout is interruptable. This is cool because 
this allows the first page to be laid out and shown while the rest 
of the document is laid out in the background in subsequent 
steps. This however makes the layout process a bit more 
complex. In short we need to remember where we were so that 
we can pick up the layout from there. Previously all we needed 
was to figure out which block we were at, but since we now have 
a tree like structure we also need to remember where in that 
tree we are. Ie the path from root to leaf.

I've represented this path with a chain of CompositeIterator 
classes. Such a compositeIterator shows where within a section 
or within a table or within a table cell we are currently and has a 
pointer to the CompositeIterator of the sub element.

The compositeIterator lets us record where in the tree we are, 
but I'd like to also change the actual way we iterate through the 
textlines.

Right now we do one textline at a time (in KoText) and walk from 
one block to the next in state->nextParag() to figure out margins 
etc (and this is where we have hacked table support in). This is 
the flat traversal I was talking about. The pseudo code is like 
this:

for every line:
  state->createLine()
  if(new paragraph)
    state->nextParag()

What I would like to do is (in KoText) to call a new method state-
>layoutNextLine() which would go to the leaf of the tree and 
layout that line. It would require some new methods but an 
example pseudo call stack would look something like this:

for every line:
  state->layoutNextLine()
    state::layoutWithinSection()
      state::layoutWithinTable()
        state::layoutWithinSection()
          state::layoutWithinBlock()
            state::createLine();

The benefit of this new approach is that the methods can do 
some work on the way back out of the calls, after the line have 
been layed out. This is very handy for tables. With the old 
approach that work could only be done retroactively when the 
nextParag was called making the code very messy.

The trouble with the current flat approach is that everything 
regarding tables and sections would have to be handled in one 
big spaghetti mess.

Overall I'd say this approach is not conceptually that different 
from the old approach. We still do one line at a time, so it's still 
interuptable. And because we still do one line at a time much of 
the current code regarding blocks, and lines can just be reused 
as is. The table code will have to be restructured bit but will 
become simpler, and best of all sub tables and sections will be 
possible to do, and the code will be much more maintainable.

The new approach will do two things differently:
 1) it does a recursive dive for each line giving better context to 
the layout process
 2) it moves the layout of the individual line to the end of that 
dive. (But note that in pre table days the old approach was in 
effect also doing it at the end. It's just because we have added 
these new sub structures that we need to move the layout of the 
individual line, to the bottom of the recursive dive.)

best regards
Casper
_______________________________________________
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]