GSoC 2011 Tables Design

GSoC 2011 Tables

This page contains technical and functionality related considerations regarding the implementation of tables in Scribus as part of Google Summer of Code 2011. Here I'll try to keep an up to date document describing the design of the implementation, a list of open technical problems and questions regarding the functionality of the tables, including a couple of use cases as well as everything else concerning my work on bringing tables support to Scribus.

General Design

As was outlined briefly in my project proposal, the tables in Scribus will be implemented as a new page item. Handling of cell content will be delegated to text frames.

Interaction Questions

In the questions below, I refer quite a lot to Adobe Indesign CS5.5. This is not because I see it as a template of good design or anything, it's just that I happen to have come across a copy of it which I have running under VirtualBox, and it helps to have something existing to discuss around. I've never even used Indesign myself before.

Table Creation/Editing

The "Table" menu of Adobe Indesign CS5.5

Is there a general consensus on how we want interaction with the tables to work? Looking at how tables work in Indesign CS5.5, their design is quite straight forward and works essentially as those found in word processors: The user is presented with a "Table" menu from which tables can be inserted and manipulated and formatted through dialogs that pop up. Something that might be different from how tables will work in Scribus is that in Indesign, tables can only exist as inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the tables on the page, while in the future, we can hopefully let the user insert the table item I'll be creating inline in running text by making it an inline object of some kind? Another thing which I think will naturally be different in Scribus is that in Scribus, editing of item properties is mostly done through the Properties palette, and not so much through dialogs that pop up (thankfully! because table editing in Indesign seems to be very dialog-intense). I guess we will have a new tab on the PP called "Table" that will be disabled unless a table is selected, similar to how it works for images?

Table/Row/Column Resizing

In Indesign, tables, rows and columns are resized by click-dragging, and I'm guessing this is how we want it to work in Scribus too? Something that comes to mind is that for most items Scribus uses a modal way of interacting with the item: In the "normal" mode, the user is able to select, move and resize an item, while in the "editing" mode (entered by double-clicking) he/she is able to perform editing actions on the item, such as inserting text in text frames, or moving vertices of a polygon. Is this modal way of working something we want for tables as well, in order for them to fit in with the Scribus way of working? If so, I'm guessing actions such as column/row resizing should be available in the "editing" mode, while in the "normal" mode the user is only able to move/resize the table?

Resizing a table in Adobe Indesign CS5.5

Resizing a table row in Adobe Indesign CS5.5

Resizing a table column in Adobe Indesign CS5.5

Styles — Worthwhile?

A while ago I took an afternoon and investigated what it takes to create a new kind of style in Scribus, thinking this is something we might want for tables. It was mostly straight forward and I ended up with a primitive skeleton of a new style which is now in my Git repo. Since then however, I've started thinking; Are styles for tables (and even for rows/columns/cells) something we really want, or are they an unnecessary complication for small benefits? I don't know about other programs, but Indesign does not have named styles for tables. Tables are simple formatted by direct editing of properties for individual tables. How common are use cases where the user would really be hampered without support for named table (and possibly cell/row/column) styles? I'd really like to get the opinion of other team members on this.

Technical Questions

Below are some of the technical questions I have to find answers to. Since the content of table cells will be represented using Scribus' regular text frames, several of the questions below are related to this.

Notification of Text Overflow in Text Frames

Using text frames for cell content means the table will have to be notified when overflow occurs in a text frame, to be able to correctly re-layout the table starting from the row in which the overflow occurred. If we eventually want to have width-growing columns, we'll also need a way to be notified when a line break is about to occur in a text frame. So the question is; do text frames currently emit any signals to indicate that content is overflowing? It seems it's not, but one place where such a signal could possibly be emitted is in PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might not be a correct solution though, perhaps the table should instead listen to insertions being made in the text frame, and query the frame for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will also need to be able to query the text frame for the height of its content, to be able to resize it correctly during table layout. Is this possible using the current API? If not, what would it take to add it?