GNOME Bugzilla – Bug 614399
Incorrect rows heights/column widths for some cells in imported XLS
Last modified: 2018-05-22 13:36:50 UTC
Created attachment 157526 [details] XLS for this bug gnumeric doesn't set properly height/width for some cells in the file imported from XLS.
Created attachment 157528 [details] Not ideal (highlighted), but much better in XL2k3
Created attachment 157529 [details] Highlighted issues in gnumeric. OO.org 3.1 doesn't import it correctly too (if anybody cares).
Note that the highlights only indicate the most obvious issues. Rows in XL are 12.75 pts/17 pixels tall while in gnumeric they are 8.25 pts/11 pixels. Font size is the same (10).
*** Bug 166824 has been marked as a duplicate of this bug. ***
Looks like for all wrong rows ROW record has "0x00 0x01 0x0f 0x00" at the end, and for right rows it's "0xc0 0x01 0x15 0x00". Special case is "0x40 0x01 0x15 0x00" -- this row is about the same incorrect in gnumeric and XL. 0xCO sets bits E and F, 0x40 sets bit E. (E - fUnsynced (1 bit): A bit that specifies whether the row height was manually set. F - fGhostDirty (1 bit): A bit that specifies whether the row was formatted. http://msdn.microsoft.com/en-us/library/dd906757%28v=office.12%29.aspx) Bit F controls index to XF, which does nothing with row height. So I believe bit E should be read like this: "If row height was set manually, then take miyRw value for height, otherwise match row height to the font size".
We are using bit E: double hu = get_row_height_units (height); sheet_row_set_size_pts (esheet->sheet, row, hu, (flags & 0x40) ? TRUE : FALSE); flags & 0x40 is bit E, so we are indicating whether the user manually set the row height. Where do you get that we should completely ignore the given row height?
When we read the row records we set: Row 13 by: sheet_row_set_size_pts (sheet=0x81e6210, row=12, height_pts=8, set_by_user=0)
Created attachment 198569 [details] [review] proposed patch This patch will increase in size all rows and columns that were not marked as having their size set by the user.
Interesting... It corrects all rows in the attached file, but only one in the file attached to #660605. For this one text in B5:E5 is ellipsised, I didn't check what could be the reason for that yet.
Andreas: interesting. Would this potentially be rather expensive?
When opening an xls files where lots of rows do not have hard (ie. user set) heights, this could theoretically be rather expensive but: If I take a gnumeric sheet with 1M rows and fill the first column with a linear series (start=0, step=1) the filling takes a very long time. If I then select the whole sheet and choose autofitting of the row heights then that takes only about 2 or 3 seconds, and in this situation _all_ 1M rows are being fitted (and undo information about the original row heights is being saved). The patch would not save undo info so it would likely be slightly faster. As a consequence I would expect this patch to only increase loading time for a file by a tiny percentage.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/134.