GNOME Bugzilla – Bug 660605
XL overrides cell borders by next cells, gnumeric doesn't (3rd party XLS file)
Last modified: 2011-10-07 18:58:35 UTC
Created attachment 197932 [details] Bottom border of row 26 cells looks thick in XL (set to 2 by top border of row 27 cells) "1C" generates XLS files with 'shared' cell borders set to non-0 for both cells. XL overrides border of the 1st cell by border of adjacent cell. XL itself does not save files this way. One of the adjacent border is set to 0 always.
Created attachment 197933 [details] Cell D7 is "all borders = 1", cell D8 is "top border = 2", "1C Enterprise" way of saving borders
Created attachment 197934 [details] Same as in comment #1 but made by XL2k7
For files in comments #1 and #2 borders are in XF records 0x3e and 0x3f.
what would happen if the cells are switched, ie. 1st cell: "border shared with second cell = 2" and 2nd cell: "all borders = 1". What would XL do?
It draws think one. I will do more tests with single/double lines borders and colors.
d7 d8 result 1 (thin) 2 (medium) 2 (medium) 2 (medium) 1 (thin) 2 (medium) 2 (medium) 5 (thick) 5 (thick) 2 (medium) 3 (dashed) 2 (medium) 3 (dashed) 2 (medium) 2 (medium) 6 (double) 2 (medium) 6 (double) 2 (medium) 8 (med-dash) 2 (medium) 8 (med-dash) 2 (medium) 2 (medium) 6 (double) 5 (thick) 6 (double) 2 (medium) 7 (hair) 2 (medium) 7 (hair) 2 (medium) 2 (medium) 5 (thick) 6 (double) 6 (double) double > thick > medium > thin > hair solid > dashed -- I didn't check all combinations, can do if required. Do you want test files?
One important case was missed. 1 (thin) 8 (med-dash) -> 8 (med-dash).
Note that we are in fact importing the complete border information. If you load the file of comment #1, select D8 format->cell->format then the top border is in fact recognized as medium. The issue is that we read the information and don't check for inconsistency. Gnumeric will always display the border of the cell to the top or left. In a way the situation is there fore worse. We are creating an inconsistent border setup when importing those files.
Valek, so with GNM_STYLE_BORDER_NONE = 0x0, GNM_STYLE_BORDER_THIN = 0x1, GNM_STYLE_BORDER_MEDIUM = 0x2, GNM_STYLE_BORDER_DASHED = 0x3, GNM_STYLE_BORDER_DOTTED = 0x4, GNM_STYLE_BORDER_THICK = 0x5, GNM_STYLE_BORDER_DOUBLE = 0x6, GNM_STYLE_BORDER_HAIR = 0x7, GNM_STYLE_BORDER_MEDIUM_DASH = 0x8, GNM_STYLE_BORDER_DASH_DOT = 0x9, GNM_STYLE_BORDER_MEDIUM_DASH_DOT = 0xa, GNM_STYLE_BORDER_DASH_DOT_DOT = 0xb, GNM_STYLE_BORDER_MEDIUM_DASH_DOT_DOT = 0xc, GNM_STYLE_BORDER_SLANTED_DASH_DOT = 0xd, what is the preference ordering: GNM_STYLE_BORDER_DOUBLE = 0x6, GNM_STYLE_BORDER_THICK = 0x5, GNM_STYLE_BORDER_MEDIUM = 0x2, GNM_STYLE_BORDER_MEDIUM_DASH = 0x8, GNM_STYLE_BORDER_THIN = 0x1, GNM_STYLE_BORDER_HAIR = 0x7, where do the other ones fit in? GNM_STYLE_BORDER_DASHED should be below GNM_STYLE_BORDER_MEDIUM but the above does not provide enough info to determine where it belongs...
Created attachment 198458 [details] [review] proposed patch Valek, please test this patch. (The choice table in excel_choose_border still needs work to address the, to me unknown, preferences between the borders.)
Andreas, Based on my latest tests prefs are: double > thick > medium > medium-dash > medium-dash-dot > slanted dash-dot > medium dash-dot-dot > thin > dashed > dotted > dash-dot > dash-dot-dot > hair So the table could be like this: ------------- = { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0 }, /* GNM_STYLE_BORDER_NONE */ { 1,0,0,1,1,0,0,1,0,1,0,1,0,0 }, /* GNM_STYLE_BORDER_THIN */ { 1,1,0,1,1,0,0,1,1,1,1,1,1,1 }, /* GNM_STYLE_BORDER_MEDIUM */ { 1,0,0,0,1,0,0,1,0,1,0,1,0,0 }, /* GNM_STYLE_BORDER_DASHED */ { 1,0,0,0,0,0,0,1,0,1,0,1,0,0 }, /* GNM_STYLE_BORDER_DOTTED */ { 1,1,1,1,1,0,0,1,1,1,1,1,1,1 }, /* GNM_STYLE_BORDER_THICK */ { 1,1,1,1,1,1,0,1,1,1,1,1,1,1 }, /* GNM_STYLE_BORDER_DOUBLE */ { 1,0,0,0,0,0,0,0,0,0,0,0,0,0 }, /* GNM_STYLE_BORDER_HAIR */ { 1,1,0,1,1,0,0,1,0,1,1,1,1,1 }, /* GNM_STYLE_BORDER_MEDIUM_DASH */ { 1,0,0,0,0,0,0,1,0,0,0,1,0,0 }, /* GNM_STYLE_BORDER_DASH_DOT */ { 1,1,0,1,1,0,0,1,0,1,0,1,1,1 }, /* GNM_STYLE_BORDER_MEDIUM_DASH_DOT */ { 1,0,0,0,0,0,0,1,0,0,0,0,0,0 }, /* GNM_STYLE_BORDER_DASH_DOT_DOT */ { 1,1,0,1,1,0,0,1,0,1,0,1,0,0 }, /* GNM_STYLE_BORDER_MEDIUM_DASH_DOT_DOT */ { 1,1,0,1,1,0,0,1,0,1,0,1,1,0 } /* GNM_STYLE_BORDER_SLANTED_DASH_DOT */ ------------ You patch (with s/gnm__border/gnm_border/) fixes borders in attached files, but not in one I've made to test all combinations at once. (Will attach right after this comment).
Created attachment 198522 [details] Crafted XLS with all 'border vs border' combinations
Created attachment 198523 [details] screenshot of the "borders.xls" file opened in xl2k7
As expected, the file of comment #12 does not trigger the code of the patch. XL2k7 does not create inconsistent borders. So the problem shown with that screenshot is a different issue.
Comment on attachment 198458 [details] [review] proposed patch committed with an adjusted choice table
The initial problem is fixed. This bug report remains open for the border issue identified by the file in comment #12 (and matching screen shot of comment #13)
Valek, would you be able to provide a file with incorrect borders where only 2 cells have borders set. (Debugging that would be much less confusing.) Thanks
I think I misunderstood the issue. I assume no that the file of comment #12 was also generated via 1C. The code path for this file does not use excel_set_xf but excel_set_xf_segment. In this case our original code just drops the second border spec rather than creating an inconsistent border situation. We need to provide the overwrite here too. I also noticed that the earlier fix assumes that the cell information is read from top left (which may always be true in the excel_set_xf case). This is clearly not the case in the excel_set_xf_segment case.
Okay, the file of comment #12 was handcrafted. Unless we encounter a file from the wild with xf-segments that are in conflict, this is not really a bug worthwhile addressing.