[scribus-dev] Preparations for GSoC

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

Elvis

>
> All-in-all I think b) would be more professional. Maybe just implement that with manual linking of table frames and save automatic linking and repeating headers/footers for after GSoC?
>
> /Andreas
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>