[scribus-dev] Preparations for GSoC

[Andreas Vox]

Am 17.05.2011 um 19:29 schrieb Elvis Stansvik:

> 2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>> 
>> Am 17.05.2011 um 14:25 schrieb Gregory Pittman:
>> 
>>> On 05/17/2011 07:53 AM, Elvis Stansvik wrote:
>>>> 
>>>> Okay, so a bit of conflicting minds about this. Perhaps I could skip
>>>> the growing for an initial version, and if I add them later on make it
>>>> an optional feature. I'll await Craig's opinion on this tonight too.
>>>> 
>>> 
>>> I think we have to consider one of the kinds of feedback we have gotten from users who want better, more flexible tables. They want to be able to easily import contents from some kind of database. Some talk about very large datasets, like catalogues and such. A table might be larger than a single page, so what would happen then? Can a table be broken into sub-tables spreading over multiple pages? What happens when you add a new row in the middle -- can a subsequent row be bumped to the next page? And for that matter, if automatic growing of cells doesn't happen, then surely editing will cause a table to overlap to the next page.
>>> 
>>> All of this would not have to be implemented now, but the basic structure of the table needs to accommodate these features to be added later.
>>> 
>>> I don't think that relying on making tables in a outside app and importing gets us any farther than we are now. If we are going to accept that, then we can expect that the day will come when LibreOffice develops enough DTP/PDF capabilities that users will skip Scribus altogether.
>> 
>> That's an important use case. I think cells (rows) need to grow automatically, otherwise editing will just be a pita. The other question is, what should happen if the existing rows don't fit into the table frame anymore: a) grow the table frame or b) cut the rest of the rows off and display an overflow marker. b) would be consistent with current text frames but would need a way how to flow the extra rows into another table frame.
> 
> Hold on! ;) "Rows don't fit into the table frame"? You're talking
> about "table frames" here, which I'm not sure what they are. I didn't
> think the tables themselves would be frames, just items. I knew I was
> going to use the existing text frames for the content of cells, but
> thought that tables would just be items, not necessarily frames. So
> you mean that tables should somehow be contained inside a frame? A
> frame which can be resized independently without affecting the size or
> layout of the table it is containing? Won't that be clumsy to use?
> 
> I imagined that if you resize a table, you're either scaling the all
> the cells inside it, or you're actually changing the width of the last
> column and the height of the last row (two ways of doing it). This is
> similar to how it works in InDesign. But you're thinking of some
> surrounding frame for the table, detached from normal table layout?
> 
> I must get this straight, because frankly I'm a little confused now :)

I use item and frame interchangeably. Where is the difference to you?

My idea is simply that table rows in table items should behave like text lines in text items.
So you would display as many rows as fit and then drop the rest and display an overflow marker.

Then a linked table item would be told the first row to display and so on.

/Andreas