Hi, just tested LibO 5.4 RC, with interest in the new management of PDF files during import. I see a very nice and commendable effort at providing a faithful and fast rendering of PDF images inserted in documents, drawing and presentations, thanks! At the same time, I also see some quite notable regressions: 1) PDF images with a transparent background are always rendered with a white solid background, which makes the PDF import completely useless when the imported image needs to appear on a colored or otherwise non-white background. This is extremely critical in some workflows. 2) The "break" action is now missing for PDF images in draw and impress. Ideally, this should still be present and transform the image in elementary LibO drawing primitives (even not perfectly), as it happens for windows metafiles. Notably, LibO already includes a codepath for doing so, since PDF images are converted in LibO drawing primitives when /opened/ rather than imported. I hope that this can be fixed before the 5.4 final release.
Can you attach a pdf file to test commented issues?
Created attachment 134454 [details] Test pdf file with no background
Created attachment 134455 [details] EMF file equivalent to PDF file (obtained by inkscape)
Created attachment 134456 [details] Drawing prepared with libo 5.4.0.1, with both the pdf and the emf image inserted in the drawing
Point 1: in the example, note how the PDF once inserted as an image in LibO draw includes a white background, when it should not (the PDF image has no background).
Point 2. Open the demo.odg file with LibO 5.3. Select the oval above the "PDF" text. Right click and see that a contextual menu appears with the "Break" option in it. Do the same with LibO 5.4. There is no "Break" option.
Confirming both aspects on Windows 10 Pro 64-bit en-US with Version: 5.4.0.3 (x64) Build ID: 7556cbc6811c9d992f4064ab9287069087d7f62c CPU threads: 8; OS: Windows 6.19; UI render: default; Locale: en-US (en_US); Calc: group But I think the loss of the "break" was expected with adoption of the pdfium based insertion. I think return of break would requires enhancement as in bug 106581 to use Skia graphics with the pdfium filtered PDF. A PDF file filter import opened into Draw still support the "break". @Miklos?
> I think return of break would requires enhancement as in bug 106581 to use Skia graphics with the pdfium filtered PDF. Wouldn't it be possible, at least for the time being, leaving in place and leveraging the 5.3 codepath for the "break", until it is possible to switch to use Skia graphics with the pdfium filtered PDF? > A PDF file filter import opened into into Draw still support the "break". If you "open" the pdf file with draw, in opposition to "inserting" it into an existing draw document, then the conversion into native LibO objects is automatic (opposed to showing the image rendered by pdfium), which is why the "break" action remains supported, I think. Indeed, the possibility of getting this behavior through the "opening" of the pdf document in draw is a useful workaround for the lack of "break" option when inserting the pdf image in an existing drawing/presentation. Another workaround is to open in inkscape, save as emf and insert the emf that supports the break action. Still, it seems a bit more complex than desirable and a bit inconsistent to have break on all vector formats (svg, emf, wmf, native metafile), but PDF.
(In reply to sergio.callegari from comment #8) > > I think return of break would requires enhancement as in bug 106581 to use Skia graphics with the pdfium filtered PDF. > > Wouldn't it be possible, at least for the time being, leaving in place and > leveraging the 5.3 codepath for the "break", until it is possible to switch > to use Skia graphics with the pdfium filtered PDF? > As in your original posting in bug 104648, _no_. Miklos' work on an "insert as image" capability (resolving bug 89727) and then moving it to a pdfium based filter simply does not support it. > > A PDF file filter import opened into into Draw still support the "break". > > If you "open" the pdf file with draw, in opposition to "inserting" it into > an existing draw document, then the conversion into native LibO objects is > automatic (opposed to showing the image rendered by pdfium), which is why > the "break" action remains supported, I think. > Yes that is correct, but the PDF structure is lost losing fidelity when printing or reexporting out of the saved ODF drawing. > Indeed, the possibility of getting this behavior through the "opening" of > the pdf document in draw is a useful workaround for the lack of "break" > option when inserting the pdf image in an existing drawing/presentation. > Another workaround is to open in inkscape, save as emf and insert the emf > that supports the break action. Still, it seems a bit more complex than > desirable and a bit inconsistent to have break on all vector formats (svg, > emf, wmf, native metafile), but PDF. There are better ghostscript based PDF conversions than Inkscape--but that is one approach.
(In reply to V Stuart Foote from comment #7) > @Miklos? Transparent PDF looks doable. "break" -- as you said -- still possible with manually opening in Draw and copying the draw page. Out-of-the-box break is possible, but a rather large work. It would require LO providing a skia interface, also pdfium's skia output (the only vector one) is not yet ready. So I guess let's keep this bug open for the transparency part.
Issue of lack of transparency in imported PDF is still present as of 6.0.0 RC1
Solid background still present as of 6.0.1 RC 1. Would be great to get a transparent background when the input PDF has no background through LibO 6. Such feature would be great particularly for presentations. Also it could allow simplification and enhancements in extensions such as the popular TeXMaths.
Still present as of 6.2.0 RC1
If I understand this bug, claim is that attached PDF has transparent background. But I see it solid in PDF viewer. Please explain how it can be seen?
(In reply to Timur from comment #14) > If I understand this bug, claim is that attached PDF has transparent > background. > But I see it solid in PDF viewer. Please explain how it can be seen? Get the impression this being going to be: PDF export not exporting transparency
To clarify, this bug is about /import/ of PDF into LibO, not /export/ from LibO. To get the issue relevance it is better to first make an example that does not use PDF images. Suppose that you are preparing a slide and you have a red background or some background objects. If you insert on it a bitmap image with some lines on a transparent background, you will see just those lines on the background elements of the slides. However if you insert an image with a non-transparent background (e.g. white), your slide will look ugly, because you'll get a big white box with the lines overlapped covering your slide background or your background objects. Same goes with PDF, but with some difference because this is a vector format. Rather than having a transparent background, in PDF you typically have no background at all, you just have the data about the foreground objects (e.g. the lines). When you import a PDF image with some lines and no background into a slide with a red background or some background elements, you expect to see just the lines on the background, not a big white box with the lines covering all the background elements. The problem is in the way in which recent LibO treats PDF by first transforming it into a bitmap for visualization. When the PDF has no background, rather than creating a bitmap with a transparent background, a bitmap with a white non-transparent background is created. And thus you get the ugly white boxes hiding the background elements. There are many ways to check if a PDF image has a background or not. I think that LibO itself is OK to make the test: (i) take the PDF file (say the demo PDF file attached to this bug) and /open/ it with LibO, rather than /importing it as an image/ (e.g., launch 'libreoffice demo.pdf'); (ii) go to Page->Properties and set all the margins to 0 (LibO may complain a little, but do not worry about it) (iii) again in Page->Properties set a solid background color (e.g., red). If you see that color in the image, then the image has no background. In fact, the LibO page background that is behind the image can "pass through". Conversely, if the PDF image has a background you will see that background and the LibO page background will not pass through.
*** This bug has been marked as a duplicate of bug 106581 ***