From Scribus Wiki
Revision as of 06:15, 2 September 2008 by Ale (talk | contribs) (New page: Category:Scribus_development =Free form tables= It's not clear to me where this fits in with UI/usability, but I was thinking that, as plans begin to form about what to do with Table...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Free form tables

It's not clear to me where this fits in with UI/usability, but I was thinking that, as plans begin to form about what to do with Tables, that perhaps we should step back and reconsider tables.

The standard way of conceptualizing a table is as we see in many word processors: a grid-like structure with so many rows, so many columns, very much like a spreadsheet, and thus the many ways that tables are typically set up to behave as spreadsheets. There is nothing wrong with this, yet nothing that restricts a table to this kind of behavior.

With Scribus, however, a table is already more of a free-form structure, with the ability to resize and move individual cells. What if we reformulated the idea of what a table is, then consider the traditional table structure a special case?

What we are looking for that is rather lacking now are the following:

  • The ability to load the cells of a table semi-automatically – with text, images, whatever
  • The ability to easily navigate from one cell to another
  • (Perhaps) some different/augmented way that styles can be applied to cells features and contents – this may automatically come from similar plans for frames in general

What if we think of each of these as also being a table?

TableX.png TableX1.png TableX2.png TableX3.png

What I am getting at is that these could also allow for loading data into them, and navigation from one to the next, if they just somehow were considered a table by Scribus.

Free-form table showing its structure

What each requires is a sense that they are a group, with some sort of sequencing, that may have rows and columns, but maybe not. There also must be allowance for the fact that one in the "table" might contain text, another an image.

Tables as an external feature

The big question for me is: are table a DTP feature? Or is it something DTP should borrow from the Office Suites?

I don't see how the table handling fits into the whole Scribus workflow, so i would suggest that Scribus creates a new frame, whose structure will be externally managed.

I'd love to propose a solution similar to the OLE embedding of MS Excel tables and graphics into MS Word documents, but -- since Scribus sets a very high standard on how the text is layout -- i can't think of any Office Suite which would deliver an output which is ready for print.

My second best suggestion, is a Scribus Plugin, which would only handle the table structure:

  • the plugins starts when creating a table frame.
  • in a separate dialog it lets you freely work on the structure of the table (new lines, new columns, merging, splitting)
  • the format of the table is stored following the odt standard in the .sla document and used by scribus to draw a text frame for each cell and for formatting them (colors, lines, padding, ...)
  • Scribus can only fill the cells with text but not change its structure.
  • The plugin can modify the table structure.

Additional features are:

  • Tables can be transformed into normal Scribus frames; the contrary may not be possible.
  • Tables can directly imported from ODT files (or copy pasted from OO.Write).
  • Rows may have a variable height.