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

[Andreas Vox]

Am 05.07.2011 um 18:56 schrieb Elvis Stansvik:

> 2011/7/5 Craig Bradney <cbradney at zip.com.au>:
>> On 7/5/11 1:43 PM, Elvis Stansvik wrote:
>> 
... let's shorten this a little :-)

>> 
>> == Problems / Questions ==
>> My biggest question right now is:
>> 
>> * What should be the general approach for integration of text frames?
>> The table will hold a set of text frames for its cells, but then? The
>> user should be prohibited from doing certain things to the text
>> frames, such as selecting and resizing them. This should be handled by
>> the table. In a way they will be similar to locked text frames, until
>> the user decides he wants to edit their content. Should I go for an
>> approach where I add a bool isTableCellContent() or similar to
>> PageItem_TextFrame? Or should PageItem_TextFrame even be inherited,
>> creating a new item for cell content? I'm open to all ideas, so if you
>> happen to have given this problem some thought, please share, because
>> frankly I haven't (yet).
>> 
>> == Next Week ==
>> I'll yet again be working on catching up with my schedule, which means
>> working on integration of text frames and basic UI. Since mid-term
>> evaluation is next week, perhaps I should also write some kind of
>> mid-term report. What do you think Craig, do you think its worthwhile
>> or just a waste of coding time? Perhaps you feel up to date enough
>> with my status. I also really should get around to making another blog
>> post showing the new features, as I've only made one post so far.
>> 
>> 
>> 
>> All in all, its very impressive. I'll catch up with you on IRC though.
> 
> Great.
> 
>> For frames.. remember we need to allow images (etc) in cells too.. so
>> considering that is important when deciding on a method. I suspect a cell
>> frame type is going to be required to inherit what is needed (only). You may
>> even find (I suspect this to be the case) that you don't actually want all
>> the mess/history that comes with text frames.
> 
> Right. For cell background images, I imagined these will be drawn by
> the table painter, same as for cell fills. I could take a look at the
> image frame for inspiration. With "(etc)", what did you have in mind
> more specifically?
> 
> Regarding mess/history of text frames, do you mean to change tactic
> and not use text frames at all? Or just that only parts of them should
> be reused? How separate is the text layout engine of Scribus from the
> text frame page item type? Is there an easy way of telling the text
> layout engine "here, layout this text in this rect"? But then, I'd
> lose a lot of text user interaction code that has gone into the text
> frame page item and its associated canvas mode, wouldn't I? I feel I
> really need to do some investigation of these parts of the code..

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