Problem description: When a spreadsheet cell has long text value (text over-flowing outside cell width), the over-flowed part was not printed, both for print preview and actual printing. Reproduced in Ubuntu 13.10 x86 and Windows 8 X86. This is a regression against 4.1.4.2. Steps to reproduce: 1. Start Calc, input "abcdefghijklmnopqrstuvwxyz" in A1 (some of the chars are outside the cell width) 2. Print preview, you only see "abcdefghijklmn" 3. Print the file, you only got "abcdefghijklmn" on the paper. Expected behavior: You got "abcdefghijklmnopqrstuvwxyz", both in print preview mode and actual printing. I believe this should be a blocker of 4.2.0 release. Operating System: All Version: 4.2.0.3 rc Last worked in: 4.1.4.2 release
Bug confirmed under Windows XP Pro x86 SP3. It is indeed a regression from branch 4.1. And a bad one...
Confirmed using Version: 4.2.0.3 Build ID: c63c03decdf780d8fb80823950665b782ec9ecd0 Ubuntu 13.10 I don't think it's a bloker but should be on the MAB, so I reduce to critical and set Highest for the new MAB policy.
For me this behavior is not a bug: 1/ spreadsheet is not a word processor 2/ it is the responsibility of the user to manage the visibility of its data 3/ if you write in the next cell on the right, the part of the text that overflow outside the cell becomes not visible, exactly as in the preview. It is true even if you put a blank character in the adjoining cell. 4/ you can manage the text formatting so that long text is automatically wrapped in the cell. 5/ use cell fusion when it is useful. That said, what seems buggy is the following: 1/ type a long text in the cell A1 so that it overflow outside the cell 2/ menu File > Page Preview ==> only the part of the text which is inside the cell width is visible 3/ type a long text in cell A2 so that it overflow outside the cell 4/ menu File > Page Preview ==> same behavior as in 2/ 5/ now, merge the cells in A1 so that the merged cell A1 contains the entire text 6/ menu File > Page Preview ==> all the text in A2 is now visible. So it seems that the cell width in column A used in the preview (idem in pdf export) is the width of A1, not the real width of the cell. I think it is not the intended behavior that the apparent width of a cell depends on the width of another cell. Best regards. JBF
I guess this bug may be caused by the patch of Bug 68961. (Sorry I just guess, I am not a developer nor IT professional.
No longer reproducible using the latest from libreoffice-4-2 branch as of today. It was reproducible as of mid last week. So, I guess some of the fixes that went in must have fixed it. Someone please verify this.
It didn't make it into the 4.2.0 branch. So I guess this will be fixed in 4.2.1.
I'll mark this as resolved for 4.2.1. Still reproducible using the libreoffice-4-2-0 branch, but it's gone in the libreoffice-4-2 branch. No idea which change has fixed it, so I'll use WORKSFORME.