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
Created attachment 100286 [details] Image showing erratic behaviour
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.
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.
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.
MABs should be priority highest.
In my view, this doesn't belong to MAB and is not of highest and major importance, as written now.
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
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
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
monilasonti@gmail.com
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.
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.
Bug still present in 5.4.5
You can try an updated version of adobe reader which supports your file or you should try adobe reader10 version as it is more updated and elite version of adobe. After trying all these methods still, you face any issue then you can visit this website https://babasupport.org/pc/acer-customer-service/161 as their technical team is very efficient and they are having hands-on training in this particular field.
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.
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)
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
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.
Forgot to mention one thing: Pictures will usually not shift around, if just a single sheet is printed.
So it happens only for multiple sheets? ,http://mrcoupon.com.tw/
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 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.
(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.
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.
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
Now, all is perfect!
Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded