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

[Elvis Stansvik]

2011/7/5 Craig Bradney <cbradney at zip.com.au>:
>
>> 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.

Alright. Good to know that you're in on it too. Sorry I missed you on
IRC tonight, had my nose deep in Qt Creator when you came by.

And I agree; as long as I keep the code clean, simple and modular, I
don't think switching out the text handling later on should be a
problem.

> 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! :)

Of course. Their wish is my command :)

On a completely different note, since I spoke some about performance
in my last report, I thought you should know I took
PageItem::DrawObj_Item(..) on a 10x10 table with triple-borders on all
edges through callgrind a couple of times today. The conclusion is
that the vast majority of the time (~90%) is spend drawing the actual
strokes. Iteration/cell accesses on the table only contributes
fractions of a percent to the running time. So as I suspected, if any
optimizations should be done it's definitely by trying to reduce the
number of drawn strokes, and not by trying to minimize cell accesses.
I actually think that the borders should be painted in four passes;
first left borders, then right borders, then bottom borders and lastly
top borders. This way the painter can be made to intelligently merge
subsequent strokes if possible, just like you suggested some time ago.
That could minimize the number of strokes significantly on tables with
homogenous borders (which will be the common case).

Anyway, that was just a side note.

> Have to crash.. gnite

You too,
Elvis