Created attachment 80919 [details] The file contains one row. Changing it's background color the hight grows unexpectedly. Problem description: Steps to reproduce: 1. open the attached xls file 2. select the whole first row by a click on the label of it 3. go to Format => Cells => Background tab 4. select any colour 5. click OK Current behavior: The line height of the row is changing much higher. Expected behavior: Changing the background color should not change the height of the row. Operating System: Windows 7 Version: 4.0.2.2 release
Hi csongor, thanks for reporting, I think nothing to do with apply a background color. If you first reset the row format to default, then apply the color doesn't change the heigh. Surely format in any cell produce this behaviour.
(In reply to comment #1) > If you first reset the row format to default, then apply the color doesn't > change the heigh. Sorry, I do not understand why I should format the row to default. I would like to keep the formatting except it's background colour. Changing the colour should preserve everything else. That's why I consider this as a bug.
Only to show that format or any other thing in one cell forces the change of the heigh when you apply the color. Try to find the cell which produces this behaviour. In fact data in column G does not fit in the cell width. Like it has the alignment properties to Wrap text automatically, it makes to change the heigh. So change the width of column G or disable the Wrap option.
(In reply to comment #3) > Try to find the cell which produces this behaviour. > > In fact data in column G does not fit in the cell width. Like it has the > alignment properties to Wrap text automatically, it makes to change the > heigh. > > So change the width of column G or disable the Wrap option. I was trying to reduce the file for this bug report. Originally it had hundreds of lines and this sole one still produces the error. If I remove any cell from the row then I am unable to illustrate the bug. I think one of the following options should work: 1. LO should present the row in double-height (that is, in the height which is determined by the G cell) 2. LO should not change the height after recolouring (or any other irrelevant modification) Instead these ones, LO behaves in a funny way. The problem is that just after importing the XLS file, LO pretends to have a normal-height row. But after any modification in this row this mimic becomes false because this is a double-height row in reality (due to the wrapping, of course). "Unfortunately" I do not have MSOffice on my computer. Could someone tell me how Excel opens this file? How is G1 presented? a) in two rows of letters, as LO shows after recolouring (that is, the whole row becomes higher) b) in one row, indicating that G1 has more rows _below_ the first row (that is, in single height but with indication of _vertical_ overflow) c) in one row, indicating that G1 has more characters beyond the cell boundary (that is, in single height but with indication of _horizontal_ overflow) d) anything else? I think a), b) and c) can also be reasonable. But the behaviour of LO is definitely wrong.
(In reply to comment #4) > (In reply to comment #3) > > Try to find the cell which produces this behaviour. > > > > In fact data in column G does not fit in the cell width. Like it has the > > alignment properties to Wrap text automatically, it makes to change the > > heigh. > > > > So change the width of column G or disable the Wrap option. > > I was trying to reduce the file for this bug report. Originally it had > hundreds of lines and this sole one still produces the error. If I remove > any cell from the row then I am unable to illustrate the bug. > > I think one of the following options should work: > > 1. LO should present the row in double-height (that is, in the height which > is determined by the G cell) > 2. LO should not change the height after recolouring (or any other > irrelevant modification) > > Instead these ones, LO behaves in a funny way. > > The problem is that just after importing the XLS file, LO pretends to have a > normal-height row. But after any modification in this row this mimic becomes > false because this is a double-height row in reality (due to the wrapping, > of course). > > "Unfortunately" I do not have MSOffice on my computer. Could someone tell me > how Excel opens this file? How is G1 presented? Better if also we can know the heigh when it was saved. > a) in two rows of letters, as LO shows after recolouring (that is, the whole > row becomes higher) > b) in one row, indicating that G1 has more rows _below_ the first row (that > is, in single height but with indication of _vertical_ overflow) > c) in one row, indicating that G1 has more characters beyond the cell > boundary (that is, in single height but with indication of _horizontal_ > overflow) > d) anything else? > > I think a), b) and c) can also be reasonable. But the behaviour of LO is > definitely wrong. Sometimes what is reasonable for one, it is not for others. With the column G designed wider enough or with Wrap option disable, there is no issue. So works as it must do it. If LO opens the file with different row heigh than when saved, can be an issue, otherwise I think not.
(In reply to comment #5) > Sometimes what is reasonable for one, it is not for others. > > With the column G designed wider enough or with Wrap option disable, there > is no issue. > So works as it must do it. > > If LO opens the file with different row heigh than when saved, can be an > issue, otherwise I think not. I understand Your arguments but I do not agree with You. :) Anyway, if we assume that recolouring of the row should reformat it's height, there is an other issue. Undo should reset the row height to it's original value but it does not. After recolouring I cannot set back the original height by undo.
I don't know, maybe there is a heigh recalculation after undo a format change. If you want, please report a new bug about the undo question. Reverted the status to UNCONFIRMED, to make easy that some one else review the bug, and if (s)he is agreed with you, (s)he will change the status to NEW. In anyhow thanks for you interest.
(In reply to comment #7) > I don't know, maybe there is a heigh recalculation after undo a format > change. > > If you want, please report a new bug about the undo question. Thanks, I reported the undo issue in Bug #65915.
I agree that behavior annoying because I also experience this with some files. But it's not reproducible with new spreadsheet. My guess it's happen on file that created with previous version LO (perhaps since 3.5.x), OOO, or MSO. Maybe you can supply more valuable informations such as that file created with what aplication/version? So someone or developer can take a look at that. LO 4.0.4.2 (Win7 32bit)
(In reply to comment #9) > I agree that behavior annoying because I also experience this with some > files. > > But it's not reproducible with new spreadsheet. My guess it's happen on file > that created with previous version LO (perhaps since 3.5.x), OOO, or MSO. > > Maybe you can supply more valuable informations such as that file created > with what aplication/version? So someone or developer can take a look at > that. The original XLS file was downloaded from the web. My internet bank offered my transaction list in XLS format and I simple downloaded it. The XLS was opened and modified by my LO 4.0.2.2 in a simple way. I deleted many rows from the file and saved back the result as XLS. Only this one row was preserved. So in last step the file was produced by LO itself.
Testing with MS Office 2007 does open the file and show Row1 with a height of 21.75 instead of 12.75 for the rest of the rows. This appears to be a problem with the LO import. LO actually corrects the problem after applying the background color.
*** Bug 65915 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 34552 ***