GNOME Bugzilla – Bug 356711
Avoid synthesizing duplicate styles when saving multi-line text in Excel format
Last modified: 2011-08-21 18:10:52 UTC
Steps to reproduce: i. In Gnumeric 1.6.3 on Ubuntu Dapper (unable to test in Windows due to bug #311354), create a multi-line text in cell A1, say, ab<Alt>+<Enter>cd. ii. Save the file as MS Excel 97 format, then open the same file in MS Excel. Actual result: A1 displayed as "abcd". However, when in edit mode or when observed in formula bar, A1 is displayed as "ab<line break>cd". Expected result: A1 displayed as "ab<line break>cd".
Confirmed with CVS and Excel 2003
We need to turn on word wrap in the format.
i confirm this on windows xp and gnumeric 1.7.6 and XL 2000, I would imagine its just the difference between linux style and windows style line breaks showing itself...
upon further testing, i find excel will fix it if you click in the formula edit gizmo and then back on the main spreadsheet, this fix seems to be permanent for the file.
*** Bug 530703 has been marked as a duplicate of this bug. ***
hmm, this should be easy to fix for anybody who can test with excel....
I've checked file saved from gnumeric with the same file re-saved from XL. For multi-line cells XL sets 'fWrap' bit in XF record ('wrap_text' in our BiffXFData struct). By changing it in hexeditor I was able to produce 'correct' file from one saved by gnumeric.
@Valek: Does this mean that whenever there is a newline used in xls, wraptext must be switched on? And so if I use a long string with a single newline, then the text will even wrap elsewhere?
To be more precise: in Gnumeric we can have: Hello World this is a long text in a small cell in a small cell, so that the text runs over the cells to the right and is shown in two lines only (since there is a newline after "text") If I switch on wrap-text it is shown as: Hello World this is a long text in a small cell although there is still only one inserted newline. So in Excel there first is not possible?
Created attachment 194269 [details] [review] proposed patch to gnumeric patch that sets the wrap text flag when exporting a cell with newlines in the type text.
Created attachment 194274 [details] [review] updated patch
Andreas, patch from comment #11 works here. XL displays "ab<CR>cdef" in A1 as two lines "ab" and "cdef", which I believe is expected result.
Valek, I have made another change to the patch before committing it. Would you please verify that the committed version in fat fixes the problem. (The change consists of not synthesizing another style if wrap-text should already be set.) 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.
Andreas, committed patch works here in part related to line wrapping. I'm not quite sure how to verify that additional style is not synthesised. I tested with wrapped lines - regular without 'wrap text' set in A1, - regular with 'wrap text' set in A2, - bold with 'wrap text' set in A3, - bold w/o 'wrap text' set in A4 to A7. Resulting file has additional XFs for cells which have to be wrapped and have no 'wrap text' set. However cells refer to only three XFs (two of the referred styles are the same 'bold, wrap', 3rd is 'regular, wrap'). I don't know if it's worth efforts to optimise gnumeric to search for same XF before synthesising a new one (each XF record is 24 bytes in size). Open/save cycle optimises it automatically, because gnumeric reads 'wrap text' for all lines with 0x0a and on saving do not synthesise additional styles.
Thanks Valek. my comment about what I changed was just intended as information. The verification was intended with regard to the original problem. Nevertheless it is interesting that you noted that we create duplicate styles. We really should check on that. This could create unnecessarily large xls files when saving a .gnumeric or .odf file. I am reopening and retitling.
We are now synthesizing each style only once. We may still end up with duplicates if we have an existing style with wrap-text and synthesize a new one, but we should have no duplication between all the synthesized ones. 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.
Confirmed. Seems to be one redundant XF per style in case I have same style cells with and w/o 'wrap_text'. It also seems to store 'original' styles of the cells for which new XFs were synthesised.