https://bugs.freedesktop.org/show_bug.cgi?id=65837
--- Comment #4 from [email protected] --- (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. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
