Difference between revisions of "Writer/New Table Model"

Revision as of 10:37, 15 November 2006

Reason/Goals

The most common table model (used in ODF, Word, HTML, etc.) bases on a table grid, with rowspan and colspan attributes set at the table cells. The Writer core table model currently uses a different approach: Writer core tables are defined recursively, i.e., a table call can contain one or more table rows. The goal of the project is to support the rowspan/colspan table model in the Writer core.

How to achieve this goal

For layout compatibility reasons we must keep the old table layout algorithms for tables created with old office versions. Since a lot of code of the current table layout algorithm is common for both table models, the current algorithm only has to be enhanced to cope with cells spanning over a couple of rows. We assume that we will not have hybrid tables, i.e., tables with subtables and rowspans.

TODO

• Implement swtable functions for new table model OK
• Layout for new tables OK
• Cursor travelling OK
• Repeated table headlines OK
• Border painting of new tables with merged borders style OK
• Border painting of new tables
• Export filters
  • XML OK
  • HTML OK
  • WW8 OK
  • RTF OK
• Import filters
  • XML OK
  • HTML OK
• Borders zuppeln
• Tagged pdf export?
• Check impact of new tables for
  • Accessibility
  • Calculation in tables

Open Questions

• Which tables should be treated as "old" tables during import? Answer: All tables containing at least one subtable.
• Rowspan: Attribute in the format of a SwTableBox or member of SwTableBox? Answer: Member of SwTableBox.
• The model shall have rowspans. Will it have colspans? Pro: this allows a simple implementation of all SwTable functions (InsertCol(), InsertRow(), Split(), Merge()). Con: Size changing funtions would be more complicated. Answer: No, the SwTableBox will not have a colspan.

Results

• During import, we have to adjust the MakeTable function in order not to create nested rows for the new table model.
• The layout has dummy cells for cells covered by rowspans. We do not want dummy cells for colspans.

The layout

Here are the golden rules for layouting rowspan tables:

• Don't panic!
• A cell with a negative row span does not grow its row
• A cell with a positive row span grows the row containing the end of the row span