[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

Hello Gregory,

2011/5/17 Gregory Pittman <gpittman at iglou.com>:
> 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.

Breaking tables across pages is indeed a non-trivial problem, and was
taken out of my GSoC project during the review of my project proposal,
partly for that reason (see [1]). However, I will of course keep in
mind that this is a desirable feature in the future. Although it might
not be implemented this summer, I'm open to discuss how this problem
could be solved in the future. I expect it to be quite tricky, but
doable.

Regarding importing of big data sets. That I agree is probably a
common use case. I also agree that table rows not growing in height
during importing of large tables would probably be a bad idea and very
frustrating for the user. It's good that you bring this up. Perhaps as
a stop-gap measure, until proper dynamic breaking of tables across
pages is implemented, the table import function could statically break
the single table into multiple smaller ones that will each fit on a
page.

I'm not quite sure I understand your last sentence though, could you
clarify? If automatic growing is not happening, why would that imply
tables overlapping 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.

Right. So that needs to be kept in mind.

>
> 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.

I agree that would feel like a defeat. Even though the tables I'll be
writing this summer won't be full-featured, my hope is of course that
one day they will be able to rival those of e.g. InDesign. And that
means it's important to at least keep advanced features like these in
mind early on.

Thanks,
Elvis