Difference between revisions of "Writer/New Table Model"

Revision as of 12:11, 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 OK
• 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