Description: When I create a 1-slide presentation containing only 1 PDF figure in Impress and try to export it to PDF, the resulting PDF shows only 50% of the original PDF figure (split vertically). When converting the PDF figure to bitmap, it exports as expected. This was tested on a fresh flatpak install. Steps to Reproduce: 1. Open Impress and import a PDF figure 2. Export the presentation to PDF 3. Open the exported PDF Actual Results: PDF figures in the exported PDF are cut vertically showing only 50% of the figure Expected Results: PDF figures in the exported PDF shows as they do in the original ODP document Reproducible: Always User Profile Reset: No Additional Info: In the LibreOffice version 7.5.9.2 (rpm pacakge), the bug was removing the PDF figure fully. In the LibreOffice version 24.2.2.2 (flatpak), the bug removes only 50% of the PDF figure.
Created attachment 193736 [details] This is how the exported PDF looks like
Created attachment 193737 [details] This is the original ODP file
I can also reproduce this bug in my local macOS build. But for me, 24.2.2.2 removes the PDF figure fully: Version: 24.2.2.2 (AARCH64) / LibreOffice Community Build ID: d56cc158d8a96260b836f100ef4b4ef25d6f1a01 CPU threads: 8; OS: macOS 14.4.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
So, to me, it looks like the X coordinate is wrong in the code that exports to PDF. I remember fixing tdf#156842 that was causing similar results, but that bug only occurred on macOS. I'll take a look at that code and see if I see anything.
I have noticed this does not happen with all PDF figures. It depends on the source of the PDF. For example, I have always seen this happen as I used the same source to produce my PDF figures, I used ROOT framework for C++ to produce them (as the one I uploaded here as an example). I have tested now with some PDF figures I downloaded from the internet and some seem to work as expected, but for some the background color of the figure turns from white to black. I do not know what is the difference in all these PDF exports, and if this is an issue of LO not supporting different PDF formats, or the sources (such as ROOT) not exporting correctly.
(In reply to LeonH from comment #5) > I have noticed this does not happen with all PDF figures. It depends on the > source of the PDF. > > For example, I have always seen this happen as I used the same source to > produce my PDF figures, I used ROOT framework for C++ to produce them (as > the one I uploaded here as an example). > > I have tested now with some PDF figures I downloaded from the internet and > some seem to work as expected, but for some the background color of the > figure turns from white to black. > > I do not know what is the difference in all these PDF exports, and if this > is an issue of LO not supporting different PDF formats, or the sources (such > as ROOT) not exporting correctly. I admit I haven't figured out how to fix this bug yet, but I have done some debugging in my local LibreOffice build and I think your bug is just a miscalculation of the X and Y coordinates of where the embedded PDF is placed with the exported PDF. I think the "white to black" bug you found is a different bug. Can you file a bug for one of those and add me to the cc list? I unzipped your attached .odp file and I could open the embedded .pdf without a problem in the macOS Preview application. It is usually fussier than Adobe Acrobat so I think the source .pdf that you put the document is OK. After that, I found that I can run LibreOffice from the command line with the following environment variable, and that will export the PDF without compression so I could edit the exported .pdf file directly: export VCL_DEBUG_DISABLE_PDFCOMPRESSION=1 With an uncompressed, exported PDF file, I have been manually changing embedded PDF to see if I can get the image to move to the left. I have had some success with that and narrowed down the cause to the following lines in the exported PDF: 8 0 obj << /Type /XObject /Subtype /Form /Matrix [ 0 -1 1 0 0 387 ] /Resources <</ColorSpace<</Cs8 9 0 R>>/ExtGState 10 0 R/Font<</F1 11 0 R/F10 12 0 R/F11 13 0 R/F12 14 0 R/F13 15 0 R/F14 16 0 R/F15 17 0 R/F2 18 0 R/F3 19 0 R/F4 20 0 R/F5 21 0 R/F6 22 0 R/F7 23 0 R/F8 24 0 R/F9 25 0 R>>/Pattern<</P01 26 0 R/P02 28 0 R/P03 29 0 R/P04 30 0 R/P05 31 0 R/P06 32 0 R/P07 33 0 R/P08 34 0 R/P09 35 0 R/P10 36 0 R/P11 37 0 R/P12 38 0 R/P13 39 0 R/P14 40 0 R/P15 41 0 R/P16 42 0 R/P17 43 0 R/P18 44 0 R/P19 45 0 R/P20 46 0 R/P21 47 0 R/P22 48 0 R/P23 49 0 R/P24 50 0 R/P25 51 0 R>>>> /BBox [ 0 0 387 567 ] /Filter/FlateDecode /Length 25435>> I was able to edit the /Matrix and /BBox attributes in the above line to get the image to move left. Hence why I think LibreOffice is just miscalculating the position. Note: LibreOffice uses the /Matrix and /BBox attributes to write the embedded PDF "inline" in the exported PDF. The harder problem is where in the LibreOffice code does the positioning coordinates get calculated? I'll start seeing if I can trace the code back to where Impress tells the export to PDF code to "place this embedded PDF at X, Y".
(In reply to Patrick Luby (volunteer) from comment #6) > (In reply to LeonH from comment #5) > > I have noticed this does not happen with all PDF figures. It depends on the > > source of the PDF. > > > > For example, I have always seen this happen as I used the same source to > > produce my PDF figures, I used ROOT framework for C++ to produce them (as > > the one I uploaded here as an example). > > > > I have tested now with some PDF figures I downloaded from the internet and > > some seem to work as expected, but for some the background color of the > > figure turns from white to black. > > > > I do not know what is the difference in all these PDF exports, and if this > > is an issue of LO not supporting different PDF formats, or the sources (such > > as ROOT) not exporting correctly. > > I admit I haven't figured out how to fix this bug yet, but I have done some > debugging in my local LibreOffice build and I think your bug is just a > miscalculation of the X and Y coordinates of where the embedded PDF is > placed with the exported PDF. I think the "white to black" bug you found is > a different bug. Can you file a bug for one of those and add me to the cc > list? > > I unzipped your attached .odp file and I could open the embedded .pdf > without a problem in the macOS Preview application. It is usually fussier > than Adobe Acrobat so I think the source .pdf that you put the document is > OK. > > After that, I found that I can run LibreOffice from the command line with > the following environment variable, and that will export the PDF without > compression so I could edit the exported .pdf file directly: > > export VCL_DEBUG_DISABLE_PDFCOMPRESSION=1 > > With an uncompressed, exported PDF file, I have been manually changing > embedded PDF to see if I can get the image to move to the left. I have had > some success with that and narrowed down the cause to the following lines in > the exported PDF: > > 8 0 obj > << /Type /XObject /Subtype /Form /Matrix [ 0 -1 1 0 0 387 ] /Resources > <</ColorSpace<</Cs8 9 0 R>>/ExtGState 10 0 R/Font<</F1 11 0 R/F10 12 0 R/F11 > 13 0 R/F12 14 0 R/F13 15 0 R/F14 16 0 R/F15 17 0 R/F2 18 0 R/F3 19 0 R/F4 20 > 0 R/F5 21 0 R/F6 22 0 R/F7 23 0 R/F8 24 0 R/F9 25 0 R>>/Pattern<</P01 26 0 > R/P02 28 0 R/P03 29 0 R/P04 30 0 R/P05 31 0 R/P06 32 0 R/P07 33 0 R/P08 34 0 > R/P09 35 0 R/P10 36 0 R/P11 37 0 R/P12 38 0 R/P13 39 0 R/P14 40 0 R/P15 41 0 > R/P16 42 0 R/P17 43 0 R/P18 44 0 R/P19 45 0 R/P20 46 0 R/P21 47 0 R/P22 48 0 > R/P23 49 0 R/P24 50 0 R/P25 51 0 R>>>> /BBox [ 0 0 387 567 ] > /Filter/FlateDecode /Length 25435>> > > I was able to edit the /Matrix and /BBox attributes in the above line to get > the image to move left. Hence why I think LibreOffice is just miscalculating > the position. Note: LibreOffice uses the /Matrix and /BBox attributes to > write the embedded PDF "inline" in the exported PDF. > > The harder problem is where in the LibreOffice code does the positioning > coordinates get calculated? I'll start seeing if I can trace the code back > to where Impress tells the export to PDF code to "place this embedded PDF at > X, Y". I can also open the PDFs normally with Okular (pdf viewer i am using), but it is strange that this would happen only with PDF figures that were generated by a specific app (in this case ROOT framework for C++) and not when for example exported by GIMP. I am not an expert on how PDF file format works, but it seems there is a slight difference between these two exports and LO is not treating them the same. But since these PDFs are working with PDF viewer such as Okular and your macOS preview, it should be possible for them to work in LO.
I think I found a possible cause for this bug: rotating the PDF. I found the following lines in the PDF embedded in your document: 51 0 obj << /Type /Page /Parent 4 0 R /MediaBox [ 0 0 595 842] /CropBox [ 20 255 407 822] /Rotate 90 /Resources 5 0 R /Contents 52 0 R >> endobj I'll have to walk through LibreOffice's export to PDF code but I am guessing that the PDF contents are supposed to be rotated using the /CropBox values but LibreOffice is using some other values (maybe the /MediaBox?). I will post again when I have some news to report.
Created attachment 193825 [details] Exported PDF after fix
(In reply to Patrick Luby (volunteer) from comment #9) > Created attachment 193825 [details] > Exported PDF after fix I have submitted a fix for this bug in the following patch: https://gerrit.libreoffice.org/c/core/+/166544 Attachment #193825 [details] shows what the exported PDF looks like with the fix. I'll post again when my fix is in a nightly master build.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4b31f87e918c38a7eb30ceb85563a5c98b426da5 tdf#160714 use crop box for bounds of embedded PDF object It will be available in 24.8.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.
I have committed a fix this bug. The fix should be in tomorrow's (25 April 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/ca574d5eef68af970cb49f90c7fc4fe813c9009c tdf#160714 use crop box for bounds of embedded PDF object It will be available in 24.2.4. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/8624309fb63fd95210ac53d06bd0de4652e4b32b tdf#160714 use crop box for bounds of embedded PDF object It will be available in 7.6.8. 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.
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-24-2-3": https://git.libreoffice.org/core/commit/f15ac9bb71266a9c1c058a782e6752129aa4d0b3 tdf#160714 use crop box for bounds of embedded PDF object It will be available in 24.2.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.
The fix for this bug is in today's (30 April 2024) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master builds install in /Applications/LibreOfficeDev.app. These builds are not codesigned like regular LibreOffice releases so you will need to execute the following Terminal command after installation but before you launch /Applications/LibreOfficeDev: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "libreoffice-7-6-7": https://git.libreoffice.org/core/commit/8dc932a517818b5b721653b372aa0124aff2375f tdf#160714 use crop box for bounds of embedded PDF object It will be available in 7.6.7. 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.