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
: low minor
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: 2022-09-30 03:53 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)
Comment 21 Timur 2019-12-04 10:31:05 UTC
I don't see a problem in exported and printed PDF with 1-page attachment 100285 [details], except row 23 image slightly over the row border. Attachment 100286 [details] Image showing erratic behavior would be minor at best, not at all major.

As for attachment 132960 [details] from Comment 12 with: "the first image in 4th sheet (Importación) is disappeared when pdf is created, other images in sheet 3 are moved", I see only one image in sheet 4 Calc and it's printed, and also all images in sheet 3. So no repro. 

Comment 15 is Impress, likely different even if related, probably there are other bugs for that. 

Comment 18 doesn't have sample document.

Conclusion: I just see a minimal move over row boundary that's minor issue.
Anyone confirming the bug please say what exactly is confirmed. 
Whoever mentioned bigger move, please attach the sample document and explain.
Comment 22 lamba84 2020-08-11 19:18:04 UTC
Comment 21:
confirmed on windows 10 x64, calc 6.4.4.2 (x64), but also previous versions had same issue.
45 pages calc document with images every 10-20 rows.
once exported to pdf images are shifted of several rows, or even on on different page.
It doesn't matter if images are anchored to page/call or if position is "protected". 

Print preview is ok

Print to PDF using Microsoft PDF printer or PDF Xchange printer give good result if images are anchored to page and position is protected.

source file is 13MB, but I'm willing to sent to anyone interested in look into it.
Comment 23 Christian 2020-09-29 13:36:12 UTC
(In reply to Timur from comment #21)
> I don't see a problem in exported and printed PDF with 1-page attachment
> 100285 [details], except row 23 image slightly over the row border.
> Attachment 100286 [details] Image showing erratic behavior would be minor at
> best, not at all major.
> 
> As for attachment 132960 [details] from Comment 12 with: "the first image in
> 4th sheet (Importación) is disappeared when pdf is created, other images in
> sheet 3 are moved", I see only one image in sheet 4 Calc and it's printed,
> and also all images in sheet 3. So no repro. 
> 
> Comment 15 is Impress, likely different even if related, probably there are
> other bugs for that. 
> 
> Comment 18 doesn't have sample document.
> 
> Conclusion: I just see a minimal move over row boundary that's minor issue.
> Anyone confirming the bug please say what exactly is confirmed. 
> Whoever mentioned bigger move, please attach the sample document and explain.

I do not think it is appropriate to play down such a bug. It has been around for what seems like an eternity and there seems to be no improvement in sight. The documents I work with quickly have over 100 pages with several images. Checking the print preview EVERY time, finding it to be OK, only to find that the .pdf version is completely unusable, soon gets on my last nerve. 

From an end user's point of view it is simply incomprehensible how something as simple as keeping pictures in place is not possible. They change their position again and again. I have already tried all possible variations of anchors. Pictures that change their position over several lines or pages are quite a problem. Please consider the problem as such and find a solution.

Unfortunately, I cannot share the documents mentioned above, as they are strictly confidential.
Comment 24 Timur 2020-09-29 14:02:07 UTC
Now we have no-value discussion that will just repel any dev but..
(In reply to Christian from comment #23)
> From an end user's point of view it is simply incomprehensible how something
> as simple as keeping pictures in place is not possible. 
Of course it's possible. Just do it yourself or find a volunteer dev. That's how LO works. Just do not reproach in vain. 

@lamba84: Version is (earliest affected) - as written. Do not "update". 

Anyone interested in this bug and mentioning big differences in printed/exported file should write exact steps to reproduce with appropriate sample document. 
No justification that one document someone has is confidential - make another that is not.

Bugzilla takes up to 20 MB. Surely if you create document, use lowest resolution to keep space and make opening fast.
Comment 25 QA Administrators 2022-09-30 03:53:46 UTC
Dear Sašo Smolej,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug