Description: Given a .odt file (see attachment) with a PDF file inside (see attachement Input.pdf). If this is exported to PDF from LO (Output.pdf), the result looks wrong (while it is shown correctly in LibreOffice itself). In the attachement, there is also a screenshot with a comparison. Steps to Reproduce: 1. Open attached .odt file 2. Export (Not print!) to PDF 3. Open result in PDF viewer and compare Actual Results: Thick green lines in the resulting PDF file Expected Results: PDF should look as it is shown in LO Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 151926 [details] Input PDF
Created attachment 151927 [details] .odt file
Created attachment 151928 [details] Output PDF
Created attachment 151929 [details] Screenshot
As suggested in IRC, here is information from Help->About: Version: 6.2.4.2 (x64) Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64 CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded
Created attachment 151940 [details] clip from Save As Export (lossless) from Draw 6.4.0 alpha0 Confirmed on Windows 10 Home 64-bit en-US (1809) with Version: 6.4.0.0.alpha0+ (x86) Build ID: 88f48b51f3cf25c78db278499d46d4913ab442ed CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded Adobe based PDF view/edit chokes on the Chromium [pdfium based] source input or the LO exported PDF MS Edge PDF renderer shows just some of the base shapes, but then stops without drawing any layers. Only the pdfium based Chrome PDF renderer [Version 75.0.3770.80 (Official Build) (64-bit)] renders the source input.pdf and the LibreOffice rendered PDF. Attaching a screen clip from Chrome viewing of LO Save As Export (lossless) from a Draw session set to full size of source PDF. And the same clip area for the original input PDF.
Created attachment 151941 [details] clip from original Input PDF The original PDF opened in Chrome Version 75.0.3770.80 (Official Build) (64-bit), so pdfium based rendering.
Performed a round trip of Input PDF (attachment 151926 [details]) taken through insertion onto Draw document canvas and then save-as exported (lossless) back to PDF. It shows the LO pdfium export with polygon fill, transparency and z-order layering of draw elements. Most obvious is the bold green line which should be underneath transparent dashed lines. Had thought mishandling of transparency was on import parsing as bug 108726 but as we are reparsing the orginal PDF stream for the export--seems to be internal against the pdfium filter?
(In reply to V Stuart Foote from comment #8) > It shows the LO pdfium s/It shows the/It shows issues with the
adjusting component...
Dear philipp.kloke, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
still repro in Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 31ed81ea71a20ec119805f66a42f99b3f80d2dc5 CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: threaded
Dear philipp.kloke, 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
I have the same issue on build 7.5.4.2 (X86_64 / AARCH64), compilation 36ccfdc35048b057fd9854c757a8b67ec53977b6, running on macOS Ventura 13.4 (build 22F66). This is a critical, basic functionality-breaking bug, and prevents me from doing exporting any of my current PhD documents, which rely heavily on embedded .PDF files, in a timely fashion.
I am now trying to isolate exactly on which LOo build the bug starts manifesting itself under macOS Ventura 13.4 build 22F66, so that I may temporarily use the immediately preceding one while you work on a fix (I have a deadline in two days, and the Windows build is giving me all sorts of font-related headaches, which might warrant a separate bug report/feature enhancement request) and also test the first offending one with other macOS versions on VMs. Stay tuned! Even if this workaround is predictably viable for the next couple of months (I'm already at version 7.3.6.1, and it seems file compatibility is not an issue), it's neither acceptable, as it is a serious WYSIWYG-paradigm-breaking regression, nor workable in the long run, as files produced with newer builds may eventually stop working or rendering correctly on the last working older version.
To clarify: I suspect all builds which offer the new dark mode – likely unrelated, but it's an important coincidence, as you'll see – suffer from this bug, and I've always hated working with LOo sticking out as the only app on my system that didn't support it and had blindingly white interface elements. As such, my plan is to use the latest build available for actual writing work, as it's much less distracting, and resort to the older one just for exporting PDF files.
Ok, I found the offending build: when it comes to stable ones, it's version 7.4.0.1, build 43e5fcfbbadd18fccee5a6f42ddd533e40151bcf . But the first one where this bug manifested itself was in 7.4.0.0alpha1, build b871abad383583f02eb49c7e49aeae01f6941072 . It's sad that I have to stick with version 7.3.7.2, because from these 7.4 builds on kerning was much improved, and being a typographer doing a PhD thesis on typography, I'd like to have the best possible typesetting and am also suspicious about potential layout preservation issues when opening files created with those newer versions on this one. But not having embedded PDFs export correctly is a complete non-starter, so I know which poison to pick. Please fix this ASAP! I will be keeping tabs on the pre-release 7.6.x.x builds…