office-collab — archive

[Svante Schubert]

In ODF the XML model for tables of presentation, text and spreadsheet table is with minor exception very similar. For example, an exception is the superset of change-tracking for spreadsheet tables. We agreed about two calls ago that we want to strive to make the system as simple as possible, therefore continue with the design idea of ODF XML or re-usage across formats and similar reuse as many operations/changes as possible across the different file formats. The table - as a de facto two dimensional array of cells - brings challenges to the designer of XML and operations. While the grouping of rows and columns are arbitrary horizontal and vertical selection of cells, in XML only rows do contain cells to avoid the problem of data redundancy. Analogue we should solve the problem of positioning cells within tables. Therefore a cell position always consists of a three positions: Table position Row position Cell position At least three positions, but it can be more as the table could be itself nested somewhere. As I have now implemented a majority of operation support for as well text and a spreadsheet, I would like to share some of my mistakes and insights made from the implementation. Text is the most frequent used document format and therefore text tables were implemented first. For text tables we created a table and explicitly tracked every addition of row and cell. Columns were created implicitly during table creation by a list of widths In Spreadsheets on the other hand the expansion of the table is close to infinite and usually only limited by the abilities of applications. A Spreadsheet with only a single empty cell is still shown by all ODF applications as 'infinite' table. By this we were forced with Spreadsheets to use a different approach and expand the ODF XML table on demand. This way of automatic expansion behavior can work and should be applied similar for text and presentation tables. To make a long implementation journey a short story, I came to the conclusion that features such as the selection of a cell range and doing various scenarios with the cells of the range such as applying a border only the outer border of cells of the range applying a border only the inner cells of the range applying styles to all cells of the range applying styles only to cells, where content or style already exist doing various style inheritance scenarios during insertion of rows/columns ... Are best implemented (best in sense of reusing as much source as possible) by dividing the following two functions the selection of cells the applying of changes to the cells, columns and/or rows of the selection Therefore I am using now only one method to select a range of cells, providing four positions:a row start & end and cell (aka column) right and left position. In case of infinity the zero was chosen as position (assuming that counting starts with 1 similar to XML/XPath). By this the cells of the complete table, rows, columns or cell ranges are handled by a single entity. After the selected table/row/column/cells have been selected (or cut out, repeated cells/rows/columns broken up and/or on demand the table is being expanded) on each table/row/column/cell a change is being applied. I have been defining changes such as format . A format dependents to the provided format properties (column, row, cell, paragraph, text properties). Dependent on the selected format properties only those part of the table are being traversed as necessary. Therefore the table needs only be traversed once for an operation (I have been editing the XML DOM directly, but the approach is mappable to all ODF table models). [If the operations are being ordered multiple/all operations could even be applied during one table traversal]. I guess the above should be enough to start a discussion on tomorrow's talk. PS: Please excuse the delay of post, currently I am changing the house with my family and packing the interior of a house into boxes is always a fountain of joy and recuperation ;) Kind regards, Svante