Difference between revisions of "Writer/New Table Model"
| Line 5: | Line 5: | ||
== How to achieve this goal == | == 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 | + | 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 new functions to the SwTable class, which are used if the table should use the new model. This allows an easy code cleanup, once the old table model has been defined deprecated. |
== TODO == | == TODO == | ||
Revision as of 13:28, 28 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 new functions to the SwTable class, which are used if the table should use the new model. This allows 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.
