[scribus-dev] Preparations for GSoC

[Andreas Vox]

Am 18.05.2011 um 18:49 schrieb Elvis Stansvik:

> Hi a.l.e.
> 
> 2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
>> hi
>> 
>>> While summarizing the thread, I also came to think of another thing;
>>> how do we want the table width to react when the table frame is
>>> resized? Should it follow the frame width, or should the width of the
>>> table be completely independent of the frame width? Or should there be
>>> something similar to what we have for images ("To Frame Size" in the
>>> Scaling properties)?
>>> 
>>> And should there be no way for the user to resize both the width and
>>> height of the table and have the row heights and column widths follow
>>> proportionally? Isn't that a valid use case?
>> 
>> personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.
>> 
>> i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).
> 
> Yes, I imagine this is the most common way of working and of course we
> should support that.
> 
>> 
>> so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.
> 
> I did not mean for this to be the only way of resizing a table of
> course. It's just that I see that it's the default behavior when
> resizing a table by dragging it's corners in InDesign; both rows and
> columns are scaled proportionally.
> 
> Imagine that you had gone through the process of setting up the widths
> and heights of the columns and rows like you describe, but then
> realize that you need the table just a little bit bigger; without this
> feature you would then have to individually make each row and column
> slightly bigger. So I think we should at least consider having the
> feature, perhaps not the default behavior, but still possible.
> 
> Now why I asked was more because I wonder how this will be implemented
> as Scribus' tables will be different in that their bottom edge will
> not follow the bottom edge of the frame. So how do we give the user
> the ability to scale the entire table?
> 
> What do you imagine should happen to the table when the user resizes
> the table by the way? Nothing? Or should it adapt it's width to the
> frame width?
> 
> I'm starting to think that nothing at all should happen actually, and
> that we should just have an "Adjust Frame to Table" option such as
> that available for images.
> 
> Then table resizing would be strictly done "inside" the frame, it's
> corner could be grabbed to resize it, and with a modifier the
> proportional behavior could be enabled, while the default would be to
> just resize the last row and column.
> 
>> 
>> of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).
> 
> Yes, I understand you favor that rows don't grow automatically, so I
> think we should support both auto-growing and fixed. Perhaps I'll
> start with the fixed behavior, as that will be easiest to implement.
> 
>> finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).
> 

Hmm. If we have the following options for column widths, it should be easy to resize columns:

- min width (default: 0)
- max width (default: infinity)
- weight (default: 1)

Then we could assign each column its minimal width and calculate the remaining space. Using the weight, the remaining space is distributed to the columns. Then, for each column which is now wider than it's maximum width, it's reset to its maximum width and weight 0 and the extra space is distributed among the remaining columns.

If the sum of all minimum width is larger than the table width, the table is clipped at the right.
If the sum of maximum widths is less than the table width, a gray area appears at the right.


Similar for rows:
- min height (default: auto, ie. depending on the contained text)
- max height (default: infinity)
- weight (default: 0, ie. rows stack up to the top with a gray area at the bottom)


Note: gray areas should be rendered transparent for print and PDF export.


Makes sense?

/Andreas