https://bugs.documentfoundation.org/show_bug.cgi?id=160714
--- Comment #6 from Patrick Luby (volunteer) <guibomac...@gmail.com> --- (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". -- You are receiving this mail because: You are the assignee for the bug.
