Download it now!
Bug 63647 - PRINTING .doc created from .odt shows top left cell of CALC OLE object with magnification filling complete object area
Summary: PRINTING .doc created from .odt shows top left cell of CALC OLE object with m...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
3.6.0.0.beta2
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2013-04-17 15:54 UTC by Llazz
Modified: 2013-06-12 10:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample to view the error. It don't print the table correctly (13.50 KB, application/msword)
2013-04-17 15:54 UTC, Llazz
Details
Image with error in page view (56.16 KB, image/jpeg)
2013-04-17 15:57 UTC, Llazz
Details
Image showing the page view correctly (58.47 KB, image/jpeg)
2013-04-17 15:58 UTC, Llazz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Llazz 2013-04-17 15:54:03 UTC
Created attachment 78141 [details]
Sample to view the error. It don't print the table correctly

Error printing (and exporting to PDF) a document saved with LibreOffice in doc format that contains cells pasted from LibreOffice Calc.

You can test it:
1. Open LibreOffice Calc and fill some cells
2. Copy and Paste these cells into LibreOffice Writer
3. Save the new document with doc format (97,2000,2003) and close it
4. Open the doc document with LibreOffice Writer
5. Select "File / Print..." and see the page view (or print it directly) or export it to pdf...
6. You can see that the cells appears with a large zoom (only appears the first cell)

Notes:
 - In the "Page Preview" of the LibreOffice Writer the page looks fine.
 - You can solve temporarily this problem editing the table in LibreOffice Writer before print/export_to_pdf it, however the error returns when you save (in doc format) and reopen it...

Thanks ;-D
Comment 1 Llazz 2013-04-17 15:57:53 UTC
Created attachment 78142 [details]
Image with error in page view
Comment 2 Llazz 2013-04-17 15:58:37 UTC
Created attachment 78143 [details]
Image showing the page view correctly
Comment 3 Rainer Bielefeld Retired 2013-04-17 17:57:08 UTC
[Reproducible] with server installation of "LibO  4.0.2.2 rc   -  English UI / German Locale  [Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3)]"  {tinderbox: @6, pull time  2013-03-26 12:00(?)} on German WIN7 Home Premium (64bit) with newly created own user profile 

1. Open new Writer document from LibO start center
2. Menu 'Insert -> Ole-Object -> Spreadsheet
3. fill spreadsheet with some contents and formatting similar to reporter's
   sample document
4. Move object borders so that they more or less exactly fit contents
5. click somewhere into the white sheet
6. Only for better visibility: click object, then 
   with <shift+Mousebutton> drag middle bottom control point 1 ... 3 object
   heights down
7. Menu 'File -> Print'
   > Object looks normal in print preview
8. Save as sample.doc
9. Menu 'File -> Print'
   > Object looks normal in print preview
10. close -> reopen
11. Menu 'File -> Print'
    Expected: Object looks normal in print preview
    Actual: A1 fills all object area in page preview
            (but will print cells with correct size but with known bugs
            due to Bug 60280)

We will have to check when that started and similar later 

@Llazz:
Please submit separate problems for different bugs (if not already submitted as Bug 60280 and one of the related ones. If you want please add me to CC in those new bus.
Comment 4 Rainer Bielefeld Retired 2013-04-17 20:49:50 UTC
Already reproducible with server installation of  "4.1.0.0.alpha0+ (Build ID: 6a393297ce6d99bbc4edefbf01ab9c5c6f0eff8) TinderBox: Win-x86@6, Branch:master, Time: 2013-01-04_01:06:01  - ENGLISH UI / German Locale  on German WIN7 Home Premium (64bit) with LO41 Masters User Profile 
Also reproducible with reporter#s sample and 4.0.0.3 

This was still ok with  server  installation of  "LOdev  4.0.0.0.beta1+   -  ENGLISH UI / German Locale  [Build ID: 6d4a55bf38a1c470c49f904dbbddf94eb2f6154)]"  {tinderbox: Win-x86@6, pull time 2012-12-17 08:36:40} on German WIN7 Home Premium (64bit) with own separate User Profile

Additional info
---------------
Most versions where the original effect does not appear open reporter 'sample.doc' showing only a small square of cell A1, rest of OLE object looks empty (quick indicator for bibisecting). But 4.0.0.3 looked normal when I opened it, but showed the problem in print preview. 

Bibisect would be useful if reproducible with Linux
Comment 5 Llazz 2013-04-18 08:05:18 UTC
(In reply to comment #3)
> 11. Menu 'File -> Print'
>     Expected: Object looks normal in print preview
>     Actual: A1 fills all object area in page preview
>             (but will print cells with correct size but with known bugs
>             due to Bug 60280)
> 
> We will have to check when that started and similar later 
> 
> @Llazz:
> Please submit separate problems for different bugs (if not already submitted
> as Bug 60280 and one of the related ones. If you want please add me to CC in
> those new bus.
@Rainer_Bielefeld:
Sorry, you are right: The cells appears correctly in page printing. This problem is only with Page View (File/Print...) and with the pdf export.
Comment 6 Joel Madero 2013-05-02 21:17:04 UTC
In linux it seems like this has always been an issue - cannot bibisect - in terms of regressions - if Rainer has confirmed regression on Windows I'll leave it but I think in Linux it can be confirmed back to at least 3.6.0.0.alpha

Removing bibisectrequest as it's not useful

Upping priority to "high" as it seems quite serious and without knowing funky workaround basically the document is useless when exported to pdf. 

Adding to MAB 3.6
Comment 7 Panos Stokas 2013-05-04 05:48:35 UTC
@Llazz:
> The cells appears correctly in page printing. This
> problem is only with Page View (File/Print...) and with the pdf export.

These are two different issues I think. Using version 4.1.0.0.alpha0+
(Build ID: 04353c273142fba62ea9b5fe62d66ee8e13814a TinderBox: Win-x86@6, Branch:master, Time: 2013-05-04_00:40:36) I can confirm that

1) Printing in a virtual PDF printer is OK

2) Export to PDF produces an empty page

3) In the Print window, the small page preview area is incorrectly displayed.

While the two issues may be related, they may also be different problems. They do fall in the Printing and PDF Export component category so I'm modifying this in the report. You may consider filing the preview-before-printing problem as a separate bug, but the export issue is definitely the major one.
Comment 8 Panos Stokas 2013-05-04 16:30:50 UTC
Versions up to 3.5 test OK. The bug was introduced in 3.6. Changed to the earliest version.
Comment 9 Michael Meeks 2013-06-12 10:33:08 UTC
This is fixed in master, and cherry-picked to 4.1 and 4.0 - for the 4.0.5 release (I believe) - looks like it was some EMF+ clipping bug at root. Either:

commit c47f0903fe0fb2f743d179d1ac9a2dcdfb19af10
Author: Radek Doulik <rodo@novell.com>
Date:   Mon Apr 29 00:00:00 2013 +0200

    Fix bnc#795857 Use correct sizes for EMF+ bitmap rendering
    
    Fix pdf export wrong size issues for embedded EMF+ images.
    
or

commit abdbb847fa135dd758ef3ef99db4c07a2671ca47
Author: Fridrich Štrba <fridrich.strba@bluewin.ch>
Date:   Fri Jun 7 15:33:13 2013 +0200

    Transform the clipping polygon before using it

Thanks for filing ! :-)