Issue 89555

Summary: Word wrapped row height in Calc changes between save and open
Product: Calc Reporter: peterthevicar <linuxiseasier>
Component: formattingAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: az77, dm, hideme, issues, mechtilde, Public2, rainerbielefeld_ooo_qa
Version: OOo 2.4.0Keywords: oooqa
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
PDF showing A1 as a single height cell
none
Extra wrapping in A1. Re-edit A1 to same text and wrapping goes away.
none
Screen capture showing auto wrapping not wrapping until file reload
none
Optimal row height not respected (save, load) none

Description peterthevicar 2008-05-16 13:03:25 UTC
When a text value nearly fills a cell, saving then opening the spreadsheet will
result in the cell having extra row height added. To reproduce:

1) Create a new Spreadsheet
2) Type 'abc abc abc' into the first cell
3) Enable word wrap: Format/Cells.../Wrap text automatically
4) Resize the cell to be JUST large enough for the text (may need to zoom in)
5) File/Save
6) File/Reload

The cell is now double height even though the text fits on one line. This fault
means that whenever you format a spreadsheet with automatic word wrap you have
to save and reload to check whether any of the formatting changes. With a large
spreadsheet this is very inconvenient.
Comment 1 Rainer Bielefeld 2008-05-16 17:13:12 UTC
I checked with "2.4.0  Multilingual version German UI WIN XP:
[680m12(Build9286)]"  and can NOT confirm the reported effect.

@peterthevicar:
Pls. specify your OS and Platform, and attach a sample file.
Comment 2 peterthevicar 2008-05-16 19:27:03 UTC
Created attachment 53723 [details]
PDF showing A1 as a single height cell
Comment 3 peterthevicar 2008-05-16 19:30:00 UTC
Created attachment 53724 [details]
Extra wrapping in A1. Re-edit A1 to same text and wrapping goes away.
Comment 4 peterthevicar 2008-05-16 19:32:02 UTC
Thanks for getting back so quickly. The original problem was with 2.4.0 on
Windows XP. It also shows up on my home system which is Debian sid, OOo version
1:2.4.0-6 update r12409 (built 1st May 2008).

Attached file displays as two single height rows (as per attached pdf which was
exported before re-opening). When you save and re-open the file the first row
has become double height. If you edit cell A1, for example delete the final 'c'
and type it in again, it will return to a single height line until you save and
reload when it will go back to double height.

Hope this helps, Peter
Comment 5 Rainer Bielefeld 2008-05-17 06:56:32 UTC
Still not reproducible with tryit3.ods, even not when I reduced width of column
in 0,01mm steps. 

@peterthevicar 
A question concerning attached version of "tryit3.ods": your description how to
reproduce the problem (what really is no step by step instruction as requested)
differs from your original report. "comments from peterthevicar Fri May 16
18:32:02" only says "save and reopen", in original report "Resize the cell to be
JUST large enough ...". Does that mean "tryit3.ods" should show a double height
row 'A' when I open it?
Please contribute more details concerning your settings (Units, standard font ...)
Comment 6 peterthevicar 2008-05-17 08:21:58 UTC
Sorry for any confusion. Yes you are right: in the tryit3.ods file I have
already completed the steps to reproduce the problem (the only tricky step is
getting the size only just large enough for the text). I then exported to pdf to
demonstrate that the line does not wrap at first. I then saved as tryit3.ods.
When I now open tryit3.ods, A1 shows as two lines high with the text at the
bottom of the cell.

I have not changed the defaults as far as I know. The text is Arial, size 10.
The only setting I changed was to enable 'Automatically wrap text' for that
cell. I have also tried with Bitstream Vera Sans (changing the cell width 
appropriately) and the problem is still there.

Thanks for looking at this, please let me know if I can help any more.

ATB, Peter
Comment 7 Rainer Bielefeld 2008-05-17 10:15:23 UTC
I still can't reproduce the problem, but I found something that might be
related. Pls see my report in  Issue 89575!
Comment 8 hennerdrewes 2008-05-17 18:30:43 UTC
I can confirm this bug.

The document opened with a row height for two text lines, although the text is
formatted in one line. Deleting one letter and reinserting it, produces one text
line, with an appropriate cell height. Saving and reopening causes the larger
cell height to reappear.

OOo 2.4.0 on Windows Vista.
Comment 9 peterthevicar 2008-05-17 20:30:12 UTC
Investigating further there is a general problem with updating the display of
auto wrapping text and I think this issue may well be a symptom of that general
problem.

To see the general problem:
1) Type 'x' into A1
2) Type 'abc abc abc' into B1
3) For B1, enable Format/Cells.../Alignment/Wrap text automatically
4) Drag the column border between A and B to the left until the text will NOT
all fit
5) You get a red arrow showing text is too big for the cell.

This is wrong as it should automatically wrap onto two lines. 

If you look at a print preview you will see the missing text mixed in with the
cell above, so A1 appears to hold 'xabc abc'

If you then save the file and reload it, the text is wrapped onto two lines. I'm
guessing that when the cell is NEARLY big enough to hold the text the same thing
happens but there is no need to display the red arrow as there is no missing text.

I also tried all this with version 3 Beta (3.0.0-2 en-US) and the same behaviour
is there.

HTH, Peter
Comment 10 Rainer Bielefeld 2008-05-18 10:19:59 UTC
@peterthevicar 
I do not understand your comment, it would really be helpful if you would be
more precise!  phrase "text 'x'" in 'A1' would help you to keep overview and
help me to understand what you are talking about

Why and how should a simple "x" wrap, as you postulate? And you enabled
"WordWrap" for 'B1' containing "abc abc abc"!

What might be "the cell above"? The cell you spoke about the sentence before or
a cell with a smaller row number (what would be some 'A0')? 

I'm sorry, but I can't spend any more time with heuristic exercises. 

Comment 11 peterthevicar 2008-05-18 23:09:31 UTC
Created attachment 53753 [details]
Screen capture showing auto wrapping not wrapping until file reload
Comment 12 peterthevicar 2008-05-18 23:20:59 UTC
I have now attached an xvidcap capture of me performing the steps I describe. To
answer your question, it is the cell B1 (abc abc abc) which wraps, not A1 (x).
The wrapped text, as you will see from the video, ends up on top of the x in A1.

HTH, Peter
Comment 13 peterthevicar 2008-05-18 23:24:49 UTC
I found I had to download the video before viewing it, but that may be just the
way my firefox is set up.
Comment 14 peterthevicar 2008-05-18 23:44:04 UTC
Looking at issue 89575 made me try enabling 'use printer metrics' in
Tools/Options/Calc/General. If that is enabled then the tryit3.ods example I
uploaded does NOT exhibit the error (unless you further reduce the width of A1).
I wonder if that is why you couldn't reproduce the error with that file? 

I have never changed that setting before, so the default must be to disable use
of printer metrics. Therefore anyone with a default install will see the error
in tryit3.ods.

HTH, Peter
Comment 15 jm38706415 2008-07-09 09:24:08 UTC
Hi peterthevicar,

I can't reproduce it on Dev_DEV300_m21_winXP Chinese. 
Comment 16 az77 2008-08-04 18:26:38 UTC
I have the same problem with version 2.4.1 on Mandriva 2008.1
This problem existed also with version 2.4.0 (on Mandriva) and version 2.3.1 (on
both Mandriva 2007.0 and Ms-xp-sp2) (French version)  It may have existed on
earlier versions.
Identical symptoms in all versions.

The problem is a little more general than given here.
My description could be useful.
I use a fixed-width font, generally size 7 or 8.

The problem occurs on the coincidence of several factors :
1) A cell in a spreadsheet contains text content which is at least almost the
width of the cell, or longer.
2) The cell in question is set to wrap.
3) The file containing the cell has been saved, and is subsequently loaded.

Result:
 Most cells meeting the above conditions are displayed with one or more extra
(blank) lines.  Extra lines are more likely when the text wraps to multiple
lines (more than 2), and if close to filling the lines it wraps to.  (i.e.,
almost one full line, almost 2 full lines, etc.)
For example, a cell which wraps to 1 1/2 lines is unlikely to display with extra
lines.  But a cell that wraps to 5 1/2 lines, or just short of 2 full lines, is
very likely to.

Note also that :
1) A freshly entered cell is always properly displayed.
2) Any change to a cell displayed improperly, (or any other cell on the same
row), results in the problem cell(s) on that row being properly displayed.
This includes reversed changes (such as adding and removing a space), toggling
the cell to no-wrap then back to wrap, or setting a cell to default format.
(A faster way to correct the display is to set an empty column to default format.)
3) If a cell wraps to multiple lines, there could be 2 or 3 extra (blank) lines.
  ** so to provide an easy test, use a cell which wraps to many lines **

(I suspect that the problem might be that Openoffice just estimates the width
required when displaying the initial matrix, but when a cell is modified, a
detailed calculation is made for every cell in the row.)

I hope this helps.
It is VERY frustrating on a large spreadsheet with a lot of wrapped text.
Comment 17 Mechtilde 2010-01-24 13:16:18 UTC
I confirm this issue 

I guess that has similar technical reason as issue 100600
Comment 18 dimitri 2013-02-07 09:09:23 UTC
... and some additional side effects dealing with wrap text and vertical alignment.

OpenOffice.org 3.4.1:

File -> New -> Spreadsheet

Enter some text in cell A2
Enter multiline text in cell A3
Enter some more text in cell A4

Click on A3: Format Cells -> Alignment -> Vertical -> Middle; check "Wrap text automatically"

Widen cell and/or change zoom levels; red arrow appears on right border indicating that the contents do not fit cell.

"Optimal Row height" not respected on save and reload.  First and last lines are guillotined.  This last one appears to be fixed in LibreOffice.

If the file is printed, adjacent cells overlap.
Comment 19 dimitri 2013-02-07 09:12:15 UTC
Created attachment 80217 [details]
Optimal row height not respected (save, load)
Comment 20 dimitri 2013-02-07 12:15:24 UTC
(In reply to comment #18)
> This last one appears to be fixed in LibreOffice.
> 

(probably not...)
Comment 21 Edward D. Isenberg 2016-06-23 19:28:53 UTC
This problem is not trivial in larger spreadsheets. The spreadsheet I regularly encounter it in has over 500 rows, and it takes me fifteen minutes or longer to reset all the row heights every time I reopen the file.