[scribus-dev] Tables GSoC - Weekly Report #5

[Craig Bradney]

> Right now it's not easy to separate the text layout code from pageitem_textframe.
> This is  done in the OIF branch, though, so the question is if it's advisable to
> hack the old code to work with the new tables.
>
> Currently each pageitem_textframe has  a storytext (named itemText). StoryText is two-part:
> one part for the text data which is shared between all linked textframes in a chain
> and a layout part which exists for each textframe.  Text editing code is spread over
> canvasmode_edit, scribusview and probably other classes (= historic mess).
>
> In the OIF branch storytext holds only the text data; the layout is split into a separate
> layout class which is based on a box model similar to TeX. These boxes allow
> layout independent of pageitems and any UI elements. In particular they offer methods
> to request the bounding box of a range of characters and to map an (x,y) position
> to a character index. 
> All editing code should eventually move into canvasmode_edit (or even a new canvasmode_textedit).
>
> My gut feeling says right now it would be best to use a slaved textframe for each table cell,
> which is not known to the rest of scribus and use that for text layout only. Then rewrite the
> editing code for tables from scratch: just insert/delete chars at the correct position, re-layout
> and render.
>
> You would have a storytext for each table cell, too. For saving you could probably use the existing
> code and use additional attributes to link the storytext to the correct table cell.
>
> I wouldn't bother with the story editor, though.
> Using story editor for editing single table cells is no fun and adapting story editor for tables is
> a no-no: story editor has to die soon, anyway.
>
> IMHO it would be acceptable if editing text in tables is suboptimal for now. We should put the effort
> into getting it right with the OIF code.
>
> /Andreas
>

Estan.. I'd go with this reasoning too.. if everything else works well,
changing a content type (including text frame rendering system) should
be not so hard.. work but work that would lean upon a lot of existing
code once OIF is complete.

As for other types.. there will be someone out there who wants text on a
path or an SVG, EPS or something else in a cell.. I guarantee it. Don't
waste time on it for now, but wait until this is in mainline and then
the RFEs will appear on bugs.scribus.net! :)

Have to crash.. gnite

Craig