Tables

From Scribus Wiki
Revision as of 22:46, 7 March 2012 by Jens (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


The following is for Tables FX, not for bread and butter tables.

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 tables 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.

Which features?

The work on the new XML format is an excellent time to lay the groundwork for a professional Tables feature that can support large projects, in the way that the FrameMaker Tables feature does.

A Tables feature for a real DTP is a schema element in its own right, with a coherent set of attributes and sub-elements. It's more than a collection of frames with borders that just happen to be next to each other.

It has some definite number of columns, and is not susceptible to being corrupted by deleting one cell out of a column -- if a column exists at all, it has a cell in every row.

Similarly, a row has a cell in every column if it exists at all. (A cell can be empty, or merged with neighboring cells, but it is incapable of being deleted or resized by itself.)

A table has header row elements and footer row elements, which are instantiated automatically when a table paginates. Layout properties of the table, such as cell margins, are inherited by every cell in the table unless locally overridden.