Bug 74009 - PRINTING: Long text flowing outside a Cell not printed
Summary: PRINTING: Long text flowing outside a Cell not printed
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.0.3 rc
Hardware: x86 (IA32) All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: BSA target:4.2.1
Keywords: regression
Depends on:
Blocks: mab4.2
  Show dependency treegraph
 
Reported: 2014-01-24 06:04 UTC by Kevin Suo
Modified: 2014-01-27 18:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-01-24 06:04:00 UTC
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
Comment 1 Pedro 2014-01-24 10:34:52 UTC
Bug confirmed under Windows XP Pro x86 SP3.

It is indeed a regression from branch 4.1. And a bad one...
Comment 2 sophie 2014-01-24 15:55:28 UTC
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.
Comment 3 Jean-Baptiste Faure 2014-01-25 08:28:45 UTC
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
Comment 4 Kevin Suo 2014-01-26 02:19:58 UTC
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.
Comment 5 Kohei Yoshida 2014-01-27 17:54:13 UTC
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.
Comment 6 Kohei Yoshida 2014-01-27 18:18:13 UTC
It didn't make it into the 4.2.0 branch. So I guess this will be fixed in 4.2.1.
Comment 7 Kohei Yoshida 2014-01-27 18:24:07 UTC
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.