Bug Hunting Session
Bug 79538 - Calc: Images move when printing or exporting to PDF
Summary: Calc: Images move when printing or exporting to PDF
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: All All
: highest major
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks: PDF-Export Calc-Images
  Show dependency treegraph
 
Reported: 2014-06-02 11:06 UTC by Sašo Smolej
Modified: 2019-10-14 00:39 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document that can be used to reproduce the issue (130.47 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-06-02 11:06 UTC, Sašo Smolej
Details
Image showing erratic behaviour (202.93 KB, image/png)
2014-06-02 11:08 UTC, Sašo Smolej
Details
ods for export to pdf with 4 sheets, view image in sheet 4: "Importación" (31.00 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-04-30 07:40 UTC, gmolleda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sašo Smolej 2014-06-02 11:06:36 UTC
Created attachment 100285 [details]
Test document that can be used to reproduce the issue

Problem description: When printing a spreadsheet (or previewing or creating PDF), images are moved, sometimes over several centimeters. This has been occuring for a long while (we've been using libreoffice since around 2.5 I think?). Reinserting images sometimes seems to fix the issue, sometimes not. It is easily the most erratic and obnoxious issue I've had to deal with.

Steps to reproduce:
1. Open attached document
2. Attempt to print the spreadsheet
3. Compare output with actual file

Current behavior:
After printing, images move from their position, sometimes regardless of compensating movement in the opposite direction.

Expected behavior:
After printing, images should stay as they  were positioned.


Also take note of the following image: http://i.imgur.com/v0AALMD.png
If you look at the part where I begun to drag and drop the image, you can see something interesting. The difference seems like the distance I should compensate for, but that is not always the case.
Operating System: Windows 7
Version: 4.2.4.2 release
Comment 1 Sašo Smolej 2014-06-02 11:08:05 UTC
Created attachment 100286 [details]
Image showing erratic behaviour
Comment 2 Yousuf Philips (jay) (retired) 2014-06-15 02:06:51 UTC
Confirmed in Linux Mint in 3.3.0, 4.2.4 and 4.3 beta. Each LibO version tested with the attachment, had variations in the positioning of the images in edit mode as well as in print mode.
Comment 3 Sašo Smolej 2014-06-15 10:09:00 UTC
Additional note: during normal usage, attempting to copy the image into Draw, resizing and then recompressing it (which I assume ends up being a completely different image) does not change the behaviour once it is inserted into Calc.

As an extra note, moving the image down does not always move the "ghost" image down as well. This is regardless of the way the image is anchored.
Comment 4 Yousuf Philips (jay) (retired) 2014-06-22 17:45:10 UTC
The main problem i've seen with Calc when it comes to images, is that it doesnt save its position according to its distance from a cell and because of this, image seem to move positions in various version of LibreOffice. My friend had an excel file that had a column of images that were all aligned in a straight line but when he opened it in Calc, the images moved slightly from their position so they were no longer aligned correctly.
Comment 5 Björn Michaelsen 2014-07-12 20:13:03 UTC Comment hidden (obsolete)
Comment 6 Timur 2014-10-13 17:18:20 UTC Comment hidden (obsolete)
Comment 7 tommy27 2014-11-30 20:12:53 UTC
still reproducible with LibO 4.3.3.2 and 4.5.0.0.alpha0+
Build ID: 84a6d8eeaab540e5b2ea3baffd919903dff8c247
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-22_23:41:04

moving to mab4.3 since 4.2.x is END OF LIFE
Comment 8 Sašo Smolej 2015-03-11 13:35:33 UTC
I have found an even more baffling example, in my case a 3-sheet calc document - not sure what's so different about this one. (currently running 4.4.0.3 build ID de093506bcdc5fafd9023ee680b8c60e3e0645d7)

1) The second image has moved to overlay some text on sheet 3 in the exported PDF, everything else is fine
2) Move second image on sheet 3 so it doesn't overlay text when moved
3) In new pdf, the second image on sheet 1 has been moved.

I can't share this particular document but hopefully the fact that the issue somehow works across sheets should be useful in tracking it down
Comment 9 Paolo Vecchi 2015-09-21 17:10:50 UTC
Bug still present in 5.0.1.2

It seems like a regression based on bug 37083 as the images shift downwards more and more with the increase of the number of pages being printed or exported in PDF.

https://bugs.documentfoundation.org/show_bug.cgi?id=37083
Comment 10 Jason 2016-08-14 11:35:19 UTC Comment hidden (no-value)
Comment 11 gmolleda 2017-04-30 07:34:57 UTC
Yes, in LO 5.3.1.2 move images if export to pdf, with 4 sheets, the graphics in sheets 3 and 4 moves its or dissapears.
Comment 12 gmolleda 2017-04-30 07:40:59 UTC
Created attachment 132960 [details]
ods for export to pdf with 4 sheets, view image in sheet 4: "Importación"

File p01datos.ods with 4 sheets, the first image in 4th sheet (Importación) is disappeared when pdf is created, other images in sheet 3 are moved.
Comment 13 Basil Eric Rabi 2018-02-22 07:32:08 UTC
Bug still present in 5.4.5
Comment 14 aabia jones 2018-03-15 05:13:34 UTC Comment hidden (spam)
Comment 15 bunkem 2018-08-22 17:47:55 UTC
Not sure if this is the same issue but export to PDF of an Impress presentation with an embedded & cropped PDF doesn't work either.

Steps to reproduce
1) Create Impress presentation
2) Create a PDF of a spreadsheet (as an example)
3) Crop the PDF to shrink to fit to the presentation
4) In the Impress presentation, Insert:Image and select the cropped PDF
5) Save the file
6) Press the export to PDF or File:Export ...
7) View the created PDF.  Either the cropped spreadsheet is missing completely or only a portion is shown.
Comment 16 Inoriona 2018-11-29 09:08:22 UTC
Bug confirmed
Version: 6.3.0.0.alpha0+ (x64)
Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55
Locale: zh-TW (zh_TW); UI-Language: en-US
Calc: threaded
Still exists in version  6.3.0.0.alpha0+ (x64)
Comment 17 imemegadon 2018-11-29 09:36:01 UTC
Bug confirmed.

Version:6.0.7.3 (x64)
Build ID:dc89aa7a9eabfd848af146d5086077aeed2ae4a5
CPU threads:8; OS:Windows 10.0; UI render:GL; 
Locale:zh-TW (zh_TW); Calc: CL
Comment 18 Fritz R. Paul 2019-02-08 10:33:07 UTC
This bug is biting us for a very long time now already. It is a big issue and should get some attention. It is still around in version 6. We already use a macro to fix the positions of the pictures, which is working fine. For many documents it is sufficient. But for some (bigger ones), the print view (which looks all right) and the actual print-out differ a lot. Maybe it will help to get some more hints:

It looks as if there would be two issues.

The first seems to be linked to a different formatting of the print-outs (doesn't matter if it is pdf export or print). Due to that, there may be some additional line-breaks. So the some lines get bigger and further lines shift downwards, but the pictures (or OLE formulas) stay at the same position relative to the sheet origin. This is independent from the pictures being anchored to the page or the cell.

The second one is worse. Here the pictures (mostly with the exception of the first one in the sheet) are just moving somewhere. There seems to be a rule behind it (e.g. all about 5 centimeters to the right). For the most time, the shift is only upwards or downwards. This effect seems to be much worse, if there are several long sheets with multiple pictures in them. This looks as if some structures used in the printing process would not be initialized correctly.

Sometimes, it can help to just change the anchor of the very last picture. But this doesn't work in all cases.

I guess everybody would be happy to have a better way to anchor pictures to a cell or cell range, with a clean relative offset.
Comment 19 Fritz R. Paul 2019-02-08 10:54:36 UTC
Forgot to mention one thing: Pictures will usually not shift around, if just a single sheet is printed.
Comment 20 bradly 2019-10-14 00:39:48 UTC Comment hidden (spam)