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
