[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>
> 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?

No difference I guess. It's just that the way you described it made me
jump a little because that's not how I had imagined it. But I think
you're actually on to a good idea on how table breaking across pages
could be implemented, in a way that would feel native to Scribus. I
like the analogy to linked text frames.

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

I like this idea, however we are getting into breaking of tables,
which is out of scope for my project. But it can't hurt to discuss
this a little, so lets follow your train of thought.

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

If we play with the idea that I'd implement linked table frames like
this, things that needs to be taken into consideration with this
approach (and any other approach for breaking tables for that matter)
are then:

What granularity of breaking do we want? Do we want to be able to
break individual rows into two parts, where as much as possible of the
row is shown on the first table frame, and then continuing on the
second (default behavior of e.g. MS Word and LibreOffice)? Or would it
suffice for a first implementation to just "move" the entire row over
to the next table frame? The latter approach is certainly the easiest
to implement. If the former is implemented, I imagine the table would
internally work with a set of N linked text frames per cell, where N
is the number of table frames the cell is visible in.

Another thing to consider is, if we do not implement the first
behavior above, but only the second, more primitive, behavior, we'll
run into the problem of what to do with a cell that spans multiple
rows and then ends up on the boundary between two linked table frames.
How would we handle this? There's no good answer to that question I
believe.

Lastly, how do we handle width of two linked table frames? Should they
both be locked to the same width? Would it even make sense if they
were not, or what would the behavior be?

But these are all run-of-the-mill issues that any table breaking
implementation will have to wrestle with. So let's hold off on this
for a while, because I think we're getting ahead of ourselves.

So lets get back to how the tables I'll be implementing should work in
their initial version.

To make sure I understand you right, I've drawn a picture and attached
it. Is that how you imagine it to work?

What do you others think of this? I kind of like it. I think not
having individual rows automatically grow will get frustrating, but
having the entire frame automatically grow I think diverges too much
from "the Scribus way". So I think this is a good middle ground. And I
also like Andreas' idea of linked table frames, even thought that is
for the future.

Regards,
Elvis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: table_overflowing.png
Type: image/png
Size: 21759 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110517/41f24e0b/attachment-0001.png>