[Scribus] Tables and how they should be

[Nik]

Hi Andreas and Jean,

My apologies for appearing rude by posting, and then not responding. I 
was away from the office sick immediately after I wrote my post, and 
have been catching up at work ever since!

Thank you both for your thoughts.

The first thing I am interested in knowing is people's preferences for 
the structure of source documents for tables. From my experience I see 
two general forms of solution:

S-1) table data embedded in the text content
S-2) table data separate (ie, in a separate source document, whether 
that be a text, image, CSV, XML, or whatever).

Both solution have their pros and cons, but I suspect that for many 
people, keeping table data embedded in the content will seem more 
natural, and easier to maintain. I also think that both can be supported 
by the same system.

The next thing I am interested in is the workflow(s) people want:

W-1) import table data from a document (ie: right-click on table; select 
  'get data'; watch table populate)

W-2) import tables as an image (ie, with no flow, no ability to cross 
page boundaries, etc).

W-3) enter table content directly within scribus

> Let's start!  :-) 
> 
> I want to drop the current solution of one-textframe-per-cell completely.

Ok, I found the frame-per-cell construct a little strange at first, but 
given Scribus' frame orientation, I got used to it, and started thinking 
on how to make it work more effectively. Things I saw as necessary were:

add row; add column; split table (to accomodate page breaks); join tables.

> What I'm unsure about is if tables should be per frame or per paragraph.

I thought a lot about making tables recognise paragraph boundaries 
automatically on import (ie, one paragraph-per-cell), but decided that 
there are enough situations where I want more than a single paragraph in 
a cell to make that solution difficult to manage.

I think that whatever solution is chosen, it should support the import 
of data with an embedded table, where the text before and after the 
table has a different number of columns to the table between them. 
Typical example is the text before and after has a single column, and 
the table has greater than one. However, having a five-column table 
floating between 2 two-column bodies of text would obviously be very useful.

> For the table structure you would create a table and choose the
> number of columns. Then you can use the mouse (or properties palette)
> to determine the column width. Combination of cells would also be possible.

I certainly think there need to be more per-table settings, such as 
borders, colours, widths and height. Setting many of these per-cell is 
tedious.

> Entering text is as in textmode, the tab key switches to the next cell 
> (tabulators would not be available in tables, then, but I think that's ok).
> Inside a cell, normal paragraph layouts would apply.

What about importing table content from a document?

> A cell's appearance would be controlled by a cell style: background, frames
> etc.
> I'd like to see the same options as for frame borders also for cells, and
> vice versa.

Definitely! I would like to be able to set borders for the entire table, 
and I'd like to be able to set just top and bottom borders for any frame.

> If tables are per frame, normal textframes would just be a 1x1 table (just
> with
> tabulators enabled).

That's an interesting idea: If tables are per-frame, then we could set 
the column count/width as we currently do in the properties box. The 
difference with a table is that instead of text flowing down each column 
and then right to the next column (depth-first), tables would flow data 
right across all columns, then down and back to the first column 
(breadth-first).

What would be required to make this work is a cell-delimiter, which 
defines when to flow to the next column in the row. From an import 
perspective, this can be selected at time of data import. Eg, for CSV 
files, selections are provided for comma, semicolon, tab, etc; for 
Word-processor documents, cell boundaries could be recognised directly 
from the content; for XML data, cell, column, and/or row boundaries 
could be set by tag name.

Once the data has been imported, scribus will need to keep track of the 
cell boundaries somehow. I suspect that a cell object would be the best 
way to go for that, but I am open to other suggestions.

If tables are per-frame, then it would help if text import could 
automatically create table frames as tables are encountered in the text. 
I'm not sure how that would affect the current importer plugin 
framework, but when I last looked at the code (1.2.x), it seemed 
possible to me.


Those are my initial thoughts - a little belatedly.

Cheers!
Nik