Difference between revisions of "Writer/New Table Model"
From Apache OpenOffice Wiki
< Writer
B michaelsen (Talk | contribs) m |
|||
| (22 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
| + | {{Writer Project|Category=Writer/Effort/Completed}} | ||
| + | __TOC__ | ||
| + | |||
== Reason/Goals == | == Reason/Goals == | ||
| Line 5: | Line 8: | ||
== How to achieve this goal == | == How to achieve this goal == | ||
| − | For layout compatibility reasons we | + | 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. |
| + | |||
| + | == TO DO == | ||
| − | + | * Implement swtable functions for new table model - OK | |
| − | + | * Layout for new tables - OK | |
| − | * | + | * Cursor traveling - OK |
| − | + | * Repeated table headlines - OK | |
| − | * | + | * Border painting of new tables - OK |
| − | * | + | * Tagged pdf export - OK |
| − | * | + | * Export filters |
| − | * Export | + | ** XML - OK |
| − | * | + | ** HTML - OK |
| − | * | + | ** WW8 - OK |
| − | ** | + | ** RTF - OK |
| − | ** Calculation in tables | + | * Import filters |
| − | ** | + | ** XML - OK |
| − | * | + | ** HTML - OK |
| + | * Select Rectangle - OK | ||
| + | * Select Row/Col - OK | ||
| + | * Calculation in tables - OK | ||
| + | * Accessibility - OK | ||
| + | * Borders zuppeln | ||
| + | * Testing | ||
== Open Questions == | == Open Questions == | ||
| − | * Which tables should be | + | * 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? | + | * 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. | + | * 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 == | == Results == | ||
| Line 33: | Line 44: | ||
* The layout has dummy cells for cells covered by rowspans. We do not want dummy cells for colspans. | * 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: | ||
| + | |||
| + | * 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 | ||
Latest revision as of 10:55, 11 November 2009
|
Please view the guidelines
|
|---|
|
Popular Subcategories: Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results. Internal Documentation: Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results. API Documentation: Ongoing Efforts: Extension:DynamicPageList (DPL), version 2.3.0 : Warning: No results. Projects on this Wiki: (edit list)
|
| Sw.OpenOffice.org |
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.
TO DO
- Implement swtable functions for new table model - OK
- Layout for new tables - OK
- Cursor traveling - OK
- Repeated table headlines - OK
- Border painting of new tables - OK
- Tagged pdf export - OK
- Export filters
- XML - OK
- HTML - OK
- WW8 - OK
- RTF - OK
- Import filters
- XML - OK
- HTML - OK
- Select Rectangle - OK
- Select Row/Col - OK
- Calculation in tables - OK
- Accessibility - OK
- Borders zuppeln
- Testing
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:
- 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
