Difference between revisions of "Writer/New Table Model"

Revision as of 14:57, 26 September 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 want to keep the old table layout algorithms for tables created with old office versions. Therefore we will introduce a new class SwTabFrm2. Since a couple of the member functions of the table model class SwTable, e.g., Split() and Merge(), can be simplyfied if they only have to deal with rowspan/colspan tables, we also want to introduce a new table model call SwTable2, with SwTable and SwTable2 inheriting from a common SwTableModel class. This allowes an easy code cleanup, once the old table model has been defined deprecated.

TODO

• Evaluate which functions of current SwTable should me made virtual at SwTableModel
• Understand the current table import/export
• Define an API for import/export of new tables
• Implement the API for new tables
• Import of new tables
• Export of new tables
• Layout for new tables
• Check impact of new tables for
  • Accessibility
  • Calculation in tables
  • Userinterface
  • Cursor travelling

Open Questions

• Which tables should be layouted using the old algorithms?
• Rowspan: Attribute in the format of a SwTableBox or 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.

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.