Description: I found a bug in PDF export of Draw when placing an image multiple times. I placed an image via drag and drop from the Finder, adjusted the size, then duplicated it via Copy and Paste two times and resized and rotated the copies then exported it to PDF. In the exported pdf there were 4 images instead of 3 and two was in bad scale and position. In another sample the third image was just distorted and misplaced. Please find three odg documents along with the corresponding pdf-s. Could you please fix it? LibreOffice 6.4.4 macOS 10.12.6, macMini 2012. It was wrong in 6.3.x which I updated but the update did not fix it. Steps to Reproduce: 1. Open ML3.odg - it contains 3 images 2. File/Export As/Export as PDF... - jpg 90%,PDF/A-1b 3. compare the original odg file and the exported pdf Or: I placed an image via drag and drop from the Finder, adjusted the size, then duplicated it via Copy and Paste two times and resized and rotated the copies then exported it to PDF. Actual Results: there are 4 images in the pdf, two of them are right, two are smaller and misplaced Expected Results: something more similar in pdf compared to what I saw on screen Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.4.2 Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; VCL: osx; Locale: en-US (en_HU.UTF-8); UI-Language: en-US Calc: threaded macOS 10.12.6, Mac mini Late 2012 attachement: 2 odg, 2 pdf, one pdf options screenshot
Created attachment 162904 [details] ML3.odg contains 3 images. Export it to PDF
Created attachment 162906 [details] pdf export of ML3.odg
Created attachment 162907 [details] ML4.odg - export it to PDF
Created attachment 162908 [details] ML4.odg exported as PDF the third image is misplaced, misscaled and distorted in exported PDF
Created attachment 162909 [details] pdf export options for ML3.odg and ML4.odg screenshot of pdf options used when exporting ML3.pdf and ML4.pdf
When I resized the image which was exported wrong, the pdf export got correct.
For me it exports fine without needing to do any resizing. Please re-test with version 7.0 Arch Linux 64-bit Version: 7.2.0.0.alpha0+ Build ID: 79ec66700266a22966d9e308a716be56c9c3a4a7 CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 30 November 2020
I tried to export the enclosed ML3.odg and ML4.odg files and got the same result as with LibreOffice 6.4.4.2. I noticed however that the output is wrong only when the Archive PDF/A-1b was selected in the pdf export dialog. Selecting another PDF/A version or unchecking the Archive checkbox creates correct pdf files. macOS 10.15.7 LibreOffice 7.0.3.1 While trying to reproduce the issue with small jpg images I also found that the problem occurs only when the image rotated by 90 degrees (partly or in whole) overlaps the other image. Repro: 1. place a larger (512px) jpg image in the center of the page 2. place another, smaller (256px) jpg image also in the center of the page, overlapping the first one. 3. in the Properties/Position and Size set the rotation of the second image to 90 degrees. 4. export to pdf, use Archive PDF/A-1b You receive a warning saying "Some objects were converted to an image in order to remove transparencies, because the target PDF format does not support transparencies..." Possibly the rotation created some transparent object from the opaque jpg-s. The resulted pdf will contain the first, not rotated image perfectly, but in the upper left corner you will get the expected result (two images overlapping) but in smaller size. Disabling Archive or choosing another archive format will fix the issue. Hope this helps.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Geza from comment #8) > I tried to export the enclosed ML3.odg and ML4.odg files and got the same > result as with LibreOffice 6.4.4.2. > I noticed however that the output is wrong only when the Archive PDF/A-1b > was selected in the pdf export dialog. Selecting another PDF/A version or > unchecking the Archive checkbox creates correct pdf files. Tried now with Archive and A-1b, but PDF export of ML3 still looks fine. Opened with Adobe Reader DC, MS Edge, Okular. Version: 7.0.3.1 (x64) Build ID: d7547858d014d4cf69878db179d326fc3483e082 CPU threads: 2; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: threaded Arch Linux 64-bit Version: 7.0.3.1 Build ID: 00(Build:1) CPU threads: 8; OS: Linux 5.9; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 7.0.3-2 Calc: threaded
Created attachment 167742 [details] Leonardo - Original odg file
Created attachment 167743 [details] Leonardo - screenshot of the resulting pdf on Windows
I could easily reproduce the problem with LibreOffice 7.0.3 on 64 bit Windows 10 as well. Please see the two Leonardo files attached. The resulting pdf was 1.9MByte so I attached a screenshot instead. The pdf was checked in latest Firefox on windows and Preview on macOS 10.15.7.
(In reply to Geza from comment #12) > Created attachment 167743 [details] > Leonardo - screenshot of the resulting pdf on Windows I don't get this problematic result on Windows with 7.0.3 and Firefox. Did you export this in Windows or macOS?
Created attachment 167759 [details] Leonardo - pdf export Windows10 LibreOffice 7.0.3 I have the same result with LibreOffice 7.0.3 on mac (macOS 10.15.7, pdf seen with Preview app) and Windows 10 (pdf seen with Firefox 83.0). This is the Leonardo703.pdf file exported on Windows 10. If you open the pdf do you see the same as on the previously attached screen shot? I see it on both platforms with the given apps. (The screenshot was created on mac) This is how I created the pdf on windows: - open Leonardo.odg - Export As... - Export As PDF... - Range: All, Images: JPEG compression, Quality 90%, Archive (PDF/A, ISO 19005), PDF/A Version: PDF/A-1b. No other checkbox have checkmark. - Export An alert comes up: Transparencies removed. - OK
Thanks, now we found the culprit: I unchecked Reduce image resolution and now I get the same result. I will investigate older versions later.
Bug is already in 6.3, but not yet in 5.0.
Bisected it in win32-6.0 First bad commit is f6daf925fee2accd961bf662a2a7070ecba21b87 is the first bad commit commit f6daf925fee2accd961bf662a2a7070ecba21b87 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Mon Sep 4 13:35:24 2017 -0700 source cf5b61967ef8647db663a1f0d699169b017916a7 source cf5b61967ef8647db663a1f0d699169b017916a7 git bisect log # bad: [bc1845d882e52469a4583747881a465749177829] source c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 # good: [cc5c4c7ed1d8d01b0063bcaaeb5f6d59282c8029] source 9feb7f7039a3b59974cbf266922177e961a52dd1 git bisect start 'master' 'oldest' # bad: [611b687719dc875499fd14d50e699b7ce871b941] source 2cd664b3d618e6085be8b44ee86eada6cd5f8789 git bisect bad 611b687719dc875499fd14d50e699b7ce871b941 # good: [1ab9d28e263358b2f569adb76bcc856198d0f435] source ccb6513baf6eae9af40eecd05a2991bdd3ce3bbf git bisect good 1ab9d28e263358b2f569adb76bcc856198d0f435 # good: [8c62e5fd421ccd2e5c767f4067798f7253965b76] source 19805f85b35672e6d0ee16f8fb4b79a3e94fc05d git bisect good 8c62e5fd421ccd2e5c767f4067798f7253965b76 # good: [170117b65d6ac2520682aed591c5429310385e4d] source 6d8598acb23bbecb55ac235c15b9e01885588ad7 git bisect good 170117b65d6ac2520682aed591c5429310385e4d # good: [58eed3875a0e92ceaf85c728d6bd1d4e084ac27c] source 9d4fc496d498f2f5c7fedba94f656ef3189b85dd git bisect good 58eed3875a0e92ceaf85c728d6bd1d4e084ac27c # bad: [23154bc8740720a2b133f8e4d8bdfefa303b72f0] source 4829d41c89acbf29db6414d026275829cf69bdc1 git bisect bad 23154bc8740720a2b133f8e4d8bdfefa303b72f0 # bad: [ce9734666dec232c705b62f1adc157eab5867c88] source 862b968d1c015bca2226f18c767d350da63517c8 git bisect bad ce9734666dec232c705b62f1adc157eab5867c88 # bad: [f5554e51cc8bce829009f82f34ae29a0a01fe1a9] source 04749a1115a44ce7a2d05c1ea6c23613feded5f9 git bisect bad f5554e51cc8bce829009f82f34ae29a0a01fe1a9 # bad: [6fb6be70917ce88faaea8134075a19da0d539cad] source 52c25a628d6cd300a0ff29f3c31e3528e3c4f8e1 git bisect bad 6fb6be70917ce88faaea8134075a19da0d539cad # good: [4b4d6689b5e729f126f756bec9c1fb0f438e2a96] source bc87d93787a5249759640a7af70846292758cd24 git bisect good 4b4d6689b5e729f126f756bec9c1fb0f438e2a96 # good: [d82811518002c0d58d69f39be438be4baba57134] source e02c57f8ec8fd98764990eeadd9d349314762f0e git bisect good d82811518002c0d58d69f39be438be4baba57134 # bad: [f6daf925fee2accd961bf662a2a7070ecba21b87] source cf5b61967ef8647db663a1f0d699169b017916a7 git bisect bad f6daf925fee2accd961bf662a2a7070ecba21b87 # good: [686ccad8d5e27442afa9219b215757cd0b2e4f35] source 723487f415d8d0474f1de7d9f01eab2aa3db947e git bisect good 686ccad8d5e27442afa9219b215757cd0b2e4f35 # first bad commit: [f6daf925fee2accd961bf662a2a7070ecba21b87] source cf5b61967ef8647db663a1f0d699169b017916a7 https://git.libreoffice.org/core/+/cf5b61967ef8647db663a1f0d699169b017916a7 commit cf5b61967ef8647db663a1f0d699169b017916a7 [log] author Caolán McNamara <caolanm@redhat.com> Thu Aug 31 16:22:58 2017 +0100 committer Caolán McNamara <caolanm@redhat.com> Sun Sep 03 21:22:35 2017 +0200 tree e3ea4b3bc0cb3a41ebc107fff6ed7496029a558a parent 723487f415d8d0474f1de7d9f01eab2aa3db947e [diff] Adding Cc: to Caolán McNamara
(In reply to pavlog from comment #18) > Bisected it in win32-6.0 > > First bad commit is > f6daf925fee2accd961bf662a2a7070ecba21b87 is the first bad commit > commit f6daf925fee2accd961bf662a2a7070ecba21b87 > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Mon Sep 4 13:35:24 2017 -0700 > > source cf5b61967ef8647db663a1f0d699169b017916a7 > > source cf5b61967ef8647db663a1f0d699169b017916a7 > > > https://git.libreoffice.org/core/+/cf5b61967ef8647db663a1f0d699169b017916a7 > commit cf5b61967ef8647db663a1f0d699169b017916a7 [log] > author Caolán McNamara <caolanm@redhat.com> Thu Aug 31 16:22:58 2017 +0100 > committer Caolán McNamara <caolanm@redhat.com> Sun Sep 03 21:22:35 2017 +0200 > tree e3ea4b3bc0cb3a41ebc107fff6ed7496029a558a > parent 723487f415d8d0474f1de7d9f01eab2aa3db947e [diff] > > > Adding Cc: to Caolán McNamara
I feel the problem is in OutputDevice::RemoveTransparenciesFromMetaFile which is extraordinarily fragile looking
https://gerrit.libreoffice.org/c/core/+/113981 seems to work to workaround the problem that cf5b61967ef8647db663a1f0d699169b017916a7 triggered. But (as does reverting the change of cf5b61967ef8647db663a1f0d699169b017916a7) one of the images is still stretched too much, that seems to be a separate older regression I will try and bisect
The other problem is since: commit 76ec54e8c9f3580450bca85236a4f5af0c328588 Author: Michael Meeks <michael.meeks@collabora.com> Date: Mon Feb 8 14:24:15 2016 +0000 tdf#97662 - Try to preserve original compressed JPEGs harder. Avoiding de-compressing and re-compressing them saves lots of time too.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7ef44142086670160756705368339a989828653a tdf#134736 move nLastBgAction to also include any trailing pops It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/2af290ddd365406ed03d144559288d4effd1323e tdf#134736 move nLastBgAction to also include any trailing pops It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79e19abad98209c0529c4b73ae947c8d1d5b6865 tdf#134736 RemoveTransparenciesFromMetaFile ruins PDFExtOutDevData groups It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
That will make it appear to do the right thing in main at least. The problem is the code that does the "objects were converted to an image in order to remove transparencies" leaves some extra metadata pointing at positions in the old metafile before was rewritten to convert the transparent objects. In the above commit rather than keep the broken metadata I throw it away when the conversion to remove transparency is done. Maybe an effort to repair it is possible/worthwhile.
Verified, thanks Arch Linux 64-bit Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: 77419c6f3aba1fd5b1660795923c22a39bdb1bad CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: kf5 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 14 April 2021
I tested it on the /daily/master/MacOSX-x86_64@tb81-TDF/2021-04-16_05.33.59/ build and the output is correct. Thank you, guys! (the pdf files are still huge and I had to add Full Disk Access to LibreOfficeDev for the save dialog to appear on macOS 10.15.7, but they are separate issues.)
I tested the latest LibreOffice 7.1.4 built at 22. Apr. 2021 on macOS but it still shows the bug. Geza (In reply to Commit Notification from comment #24) > Caolán McNamara committed a patch related to this issue. > It has been pushed to "libreoffice-7-1": > > https://git.libreoffice.org/core/commit/ > 2af290ddd365406ed03d144559288d4effd1323e > > tdf#134736 move nLastBgAction to also include any trailing pops > > It will be available in 7.1.3. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #25) > https://git.libreoffice.org/core/commit/ > 79e19abad98209c0529c4b73ae947c8d1d5b6865 > > tdf#134736 RemoveTransparenciesFromMetaFile ruins PDFExtOutDevData groups > > It will be available in 7.2.0. This would need to be backported to 7.1, I assume