[Scribus] Tables and how they should be
Mon Jul 31 13:06:10 CEST 2006
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
> 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
> 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
> 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
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.
More information about the scribus