Created attachment 200936 [details] A sample file to reproduce this issue Steps: - Open the sample file in Libreoffice 25.2.0.0.alpha0+ or later. - Select: File > Export As > Export Directly as PDF - Open the file in a PDF viewer application that uses poppler like: Evince, or Okular, or Papers Result: - The Exported PDF fails to open in the PDF viewer. - It will open in a Browser PDF viewer like Firefox or chrome. A bisect indicates that this issue started with this commit: https://git.libreoffice.org/core/+/462d85709ead9c7cec33ce58fc608997263cb6aa%5E! https://gerrit.libreoffice.org/c/core/+/170900 commit 462d85709ead9c7cec33ce58fc608997263cb6aa [log] author Armin Le Grand (Collabora) <Armin.Le.Grand@me.com> Tue Jul 23 13:26:34 2024 +0200 committer Armin Le Grand <Armin.Le.Grand@me.com> Tue Jul 23 18:35:26 2024 +0200 tree 3eef2f07a6bef84a3ba02d49c9536ab58d5abfbf parent 863b90e33c4b9964a697684887aeb42cc538b019 [diff] CairoSDPR: Support alpha for BitmapPrimitives The bad commit in the Bibisect 25.2 bibisect repo is: 028867b464ec3569c3fbc557a5598259c4c7db2e This commit causes another issue with Exported tagged PDF, as they are abnormally large in size. But I am not sure if that should be a separate issue. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 462d85709ead9c7cec33ce58fc608997263cb6aa CPU threads: 20; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 200937 [details] The output PDF that fails to open
I made a mistake in the second step, what I meant was: Select: File > Export As > Export as PDF Sorry for this mistake.
Reproducible Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 3158b14e0b26875300a8098bc117a5e69b76f48f CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded Deleting one of the shapes before exporting shows the issue. But not sure if it is a LibreOffice bug or Adobe Acrobat but.
Hello Jazevedo, Thank you for reporting the bug. I can confirm that the bug is present in master. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
This is LO bug. Although some PDF readers still can open it, prevoiously all could and size is much bigger.
Oddly, attempting to open the sample ODT file in an effort to reproduce this bug crashes my LibreOffice entirely. Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 94231af057db7871fb993582e2015c0fa21dde46 CPU threads: 16; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
> Oddly, attempting to open the sample ODT file in an effort to reproduce this bug crashes my LibreOffice entirely. I had no such crash on Debian 13 (Trixie) with: Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1d52b5b08952685d31902cc2ec37c50ec04d6f83 CPU threads: 20; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Alan from comment #6) > Oddly, attempting to open the sample ODT file in an effort to reproduce this > bug crashes my LibreOffice entirely. Related to: Skia/Vulkan. Covered by Bug 166715
Taking a look...
Indeed produces a bad PDF. Looked at the document. Looks simple at 1st view, what is that purple ting? It's a DrawShape. Removed it, still bad. Found out there is a 2nd DrawShape (need to use navigator) with a PatternFill. Removed that, better export, seems to be the bad boy. Could someone please try to reduce the bugdoc to something simple? When looking at the created PDF it has MASSES of FormControl things - maybe errors, maybe there are hidden ones in that doc? Where does it come from? How was it produced? Will now try to create sth. more simple .e.g. draw with singe obj with that pattern fill...
Created attachment 201224 [details] Simplified BugDoc, draw, 1 object, pagesized, pattern 5%, 96% transparency Seems to create same effect, PDF is ca. 4,7MB
PatternFil combined with transparency always was a problem. There must have been code somewhere to 'catch' stuff like this, maybe my changes have broken that. Building version before 462d85709ead9c7cec33ce58fc608997263cb6aa to be able to compare-debug...
First thought was that old version did somehow avoid to use FillGraphicPrimitive2D::create2DDecomposition, but it does not. It creates all the tiles and exports them. I checked that it uses PDFWriterImpl::createBitmapEmit and exports 11998 times the same bitmap using a reference. But that is not written to the pdf, instead a bitmap object gets created. Not found out yet where that happens. One difference is that in old version the PolyPolygonGraphicPrimitive2D::create2DDecomposition creates a FillGraphicPrimitive2D embedded to a MaskPrimitive2D, all that embedded to an UnifiedTransparencePrimitive2D. In createPolyPolygonFillPrimitive a PolyPolygonGraphicPrimitive2D is created and embedded to a UnifiedTransparencePrimitive2D. The new version of createPolyPolygonFillPrimitive directly creates a PolyPolygonGraphicPrimitive2D with added transparency. In PolyPolygonGraphicPrimitive2D::create2DDecomposition that gets decomposed to a FillGraphicPrimitive2D with directly added transparency and that embedded to a MaskPrimitive2D. Need to check where the optimization is in the old stuff and how it gets triggered...
It looks like VclMetafileRenderer and thus PDF export uses that for a tiled fill that has a transparency all is encapsulated in a single UnifiedTransparencePrimitive2D. This can be done in two places: (a) In FillGraphicPrimitive2D::create2DDecomposition when rAttribute.getTiling() (b) In VclMetafileProcessor2D for case PRIMITIVE2D_ID_FILLGRAPHICPRIMITIVE2D When doing in (a) a transparency would in general no longer be added to the Primitive that gets 'tiled'. Since this uses create2DDecompositionOfGraphic this canm be (depending on GraphicType) AnimatedGraphicPrimitive2D, EmbeddedSVG, or BitmapPrimitive2D, more for GraphicType::GdiMetafile. When doing in (b) I could limit to GraphicType::Bitmap and !IsAnimated() and !getVectorGraphicData(). Unsure if this should be limited to PDF export or all Metafile creating calls. Opting for (b), but have to experiment...
This (b) works in principle, not sure if to do only for PDF export, have to experiment on that one.
I thought if only doing this for the PDF export case would make sense, but all exports still based on metafile potentially have this problem, so better do it in general for Metafile already. Checking results...
Solution is on gerrit, see https://gerrit.libreoffice.org/c/core/+/186630
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/846b18650c54e60a0e30b99c8980e39ee56c589f tdf#166709 special handling of transparency for metafile/PDF It will be available in 26.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.
Created attachment 201344 [details] Result of PDF export using TransparencePrimitive2D
Created attachment 201345 [details] Result of PDF export using UnifiedTransparencePrimitive2D
Continued to experiment. Unexpectedly the size of the exported PDF using the simplified bugdoc from comment 11 is quite different (not as different as with the error, though): (a) with UnifiedTransparencePrimitive2D we get 47.5kb (b) with TransparencePrimitive2D we get 30.8 kb The current fix uses (a), so I think about using (b) in general. To decide that I would need information about which of the results as PDF has the better quality. Can someone help here? I would need someone to check added outputs from comments 19 and 20 and tell me which has the better quality. If the quality of the smaller on eis OK we can switch to that solution and save some space for the user :-)
More info from debugging: (a) exports a UnifiedTransparencyGroup with those (11600 something?) 8x8 pattern bitmaps, but references that using only one instance. That UnifiedTransparencyGroup seems to be packed into a single sub-object, also being a PDF part/file (?) (b) uses ConvertToBitmap and creates a single bitmap with the painted tiled pattern - so the orig 8x8 is not part of the PDF anymore. This seems to be the more general solution, will always be smaller independent of the bitmap used as pattern. Hmmmm...
Tried to open those PDFs with LibreOffice: (a) opens VERY slow indeed creates those 11600 bitmaps with transparency as DrawObjects -> argh! (b) opens fast and just has a single SdrObject with that TransparenceBitmap Thus this seems clearly to be an argument for (b), too, besides the filesize...
> I would need someone to check added outputs from comments 19 and 20 and tell me which has the better quality. Unfortunately I'm just a high-level / end-user here. All I noticed (thanks Joao for creating a public reproducer for this) is that a template that I use frequently results in a PDF export that is then not possible to open in most PDF readers. As long as that's working again, I'm fine with any solution that you find reasonable.
Okay, so I decided to use (b), added change after some more experimenting, the advantages seem clear. Added now code that uses directly TransparencePrimitive2D, plus bool to configure, see https://gerrit.libreoffice.org/c/core/+/186721
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/08ae179c76ba77c3c497782ab92d349a8c1140f4 tdf#166709 better to use TransparencePrimitive2D for metafile It will be available in 26.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.
Tested the fix with the original reproducer sample. The patch fixed the issue. The output PDF immediately opens in both Okular, papers and Evince. And is: 22.6 kB in size. Thanks for the fix Armin Le Grand Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 024053c0c140e1d167a0276f1885a21a160b45ac CPU threads: 20; OS: Linux 6.12; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 201374 [details] Output PDF after the fix.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/a514b0569ca1014d2060340457c32daf6b8dfbaf tdf#166709 special handling of transparency for metafile/PDF It will be available in 25.8.0.0.beta2. 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.
Armin Le Grand (Collabora) committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/3cff0b3ff4f5f16a0bca2694134e7d2e511b7c79 tdf#166709 better to use TransparencePrimitive2D for metafile It will be available in 25.8.0.0.beta2. 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.