GNOME Bugzilla – Bug 704563
ods style import/export broken
Last modified: 2013-07-20 20:36:38 UTC
The attached gnumeric file has a 128k row red area. All of column C. After ssconvert ods-style.gnumeric /tmp/ooo.ods and re-loading the resulting ods file, only C1 is red. Localc sees the same. Note: the file is meant to be fairly evil: when we manage to save it right, I am not sure it will load right. Specifically, will the entire C column be red or only the initial 64k rows?
There is no file attached...
Using my own file I note: This works fine for 1.10.17 but not for current git.
I don't know what LoCalc does but the file has: <table:table table:name="Sheet1" table:style-name="ta-0x8ebd020" table:print="true"> <office:forms form:automatic-focus="false" form:apply-design-mode="false"> <form:form/> </office:forms> <table:table-column table:style-name="ACOL-0" table:number-columns-repeated="2"/> <table:table-column table:default-cell-style-name="ACE-0x8e9bb3c" table:style-name="ACOL-0"/> <table:table-column table:style-name="ACOL-0" table:number-columns-repeated="125"/> <table:table-row table:style-name="AROW-0" table:number-rows-repeated="128"> <table:table-cell/> </table:table-row> <table:named-expressions> <table:named-expression table:name="Print_Area" table:expression="of:=#REF!" table:base-cell-address="$'Sheet1'.$A$1"/> <table:named-expression table:name="Sheet_Title" table:expression="of:="Sheet1"" table:base-cell-address="$'Sheet1'.$A$1"/> </table:named-expressions> </table:table> So every cell in column 3 should use table:default-cell-style-name="ACE-0x8e9bb3c" which is <style:style style:name="ACE-0x8e9bb3c" style:family="table-cell" style:data-style-name="General"> <style:table-cell-properties fo:background-color="#ff0000" fo:border-top="0.000cm none #c7c7c7" fo:border-bottom="0.000cm none #c7c7c7" fo:border-left="0.000cm none #c7c7c7" fo:border-right="0.000cm none #c7c7c7" style:diagonal-bl-tr="0.000cm none #c7c7c7" style:diagonal-tl-br="0.000cm none #c7c7c7" style:vertical-align="bottom" fo:wrap-option="no-wrap" style:shrink-to-fit="false" style:writing-mode="page" style:glyph-orientation-vertical="auto" style:cell-protect="protected" style:rotation-align="none" style:rotation-angle="0" style:print-content="true" style:decimal-places="13" style:text-align-source="value-type" style:repeat-content="false"/> <style:paragraph-properties style:writing-mode-automatic="true" fo:text-indent="0.00pt"/> <style:text-properties text:display="true" fo:font-weight="normal" fo:font-style="normal" style:text-line-through-type="none" style:text-line-through-style="none" style:text-underline-type="none" style:text-underline-style="none" style:text-underline-width="auto" style:text-position="0% 100%" fo:font-size="10.00pt" fo:color="#000000" fo:font-family="Sans"/> </style:style> This style should give us red background: fo:background-color="#ff0000" So I would think that we are writing the correct file (in both 1.10.17 and current git), but (for both versions with respect to git generated file) we import it incorrectly.
LO reads my file correctly if I had <table:table-row table:style-name="AROW-0" table:number-rows-repeated="128"> <table:table-cell table:number-columns-repeated="128"/> </table:table-row> Which makes some sense, if we do not consider implied cells.
Created attachment 249647 [details] ods-style.gnumeric
We are now writing a file that localc reads correctly. Gnumeric (both 1.10.17 and git) seem to be reading the first rows correctly but not the later: If the file has few rows (128 or 256 ...) it only reads the first row correctly. If the file has 262144 rows, then teh first 128 rows are read correctly.
I see what is going on: we have: /* default cell styles are applied only to cells that are specified * which is a performance nightmare. Instead we apply the styles to * the entire column or row and clear the area beyond the extent here. */ rows = state->extent_style.row; if (state->extent_data.row > rows) rows = state->extent_data.row; cols = state->extent_style.col; if (state->extent_data.col > cols) cols = state->extent_data.col; cols++; rows++; if (cols < max_cols) { range_init (&r, cols, 0, max_cols - 1, max_rows - 1); sheet_style_apply_range (state->pos.sheet, &r, sheet_style_default (state->pos.sheet)); } if (rows < max_rows) { range_init (&r, 0, rows, max_cols - 1, max_rows - 1); sheet_style_apply_range (state->pos.sheet, &r, sheet_style_default (state->pos.sheet)); } So we are clearing the styles beyond state->extent_style and state->extent_data but apparently are not counting the specified but empty cells at the end.
This all has to do with the stupid: 19.615 table:default-cell-style-name The table:default-cell-style-name attribute specifies a default cell style. Cells defined by a <table:table-cell> element that do not have a table:style-name attribute value use the specified default cell style. So technically if there was a row that has no cells specified the column style would not apply. (I can't really see us doing that). Clearing styles below and to the right of specified cells makes sense, but to do that we need to count the range of the table:cell elements, not the data and style extents!
Morten, this would all be so much simpler if we would preparse the tables to determine their size first. We could then create the sheets with the proper size and immediately in the correct order. When we parse the sheet the second time we can then apply the styles to the correct regions. Unless I am hearing from you that I shouldn't do that I will work on that.
I have committed a fix that handles the issue at hand for files that are less than 64K rows and 128 columns.
Andreas: I don't mind that, but a quick look says we have to parse pretty much everything, i.e., we have to use the same parser and just not apply the contents.
Yes I know. But on the plus side there seem to be lots of little hacks in the current code that should not be needed anymore.
We are now preparsing and creating sheets of the appropriate size. I am keeping this bug open since we still have to go through the code for the second parse to remove such things as extending the sheets.
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.