Bug 166709 - Writer doc with shape exported as PDF fails to open in PDF reader.
Summary: Writer doc with shape exported as PDF fails to open in PDF reader.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
25.2.0.0 alpha0+
Hardware: All All
: medium normal
Assignee: Armin Le Grand (allotropia)
URL:
Whiteboard: target:26.2.0 target:25.8.0.0.beta2
Keywords: bibisected, bisected, filter:pdf, regression
Depends on:
Blocks: CairoSDPR
  Show dependency treegraph
 
Reported: 2025-05-23 21:27 UTC by Jazevedo
Modified: 2025-06-28 20:07 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
A sample file to reproduce this issue (13.31 KB, application/vnd.oasis.opendocument.text)
2025-05-23 21:27 UTC, Jazevedo
Details
The output PDF that fails to open (5.11 MB, application/pdf)
2025-05-23 21:29 UTC, Jazevedo
Details
Simplified BugDoc, draw, 1 object, pagesized, pattern 5%, 96% transparency (8.03 KB, application/vnd.oasis.opendocument.graphics)
2025-06-12 12:36 UTC, Armin Le Grand (allotropia)
Details
Result of PDF export using TransparencePrimitive2D (30.08 KB, application/pdf)
2025-06-18 12:29 UTC, Armin Le Grand (allotropia)
Details
Result of PDF export using UnifiedTransparencePrimitive2D (46.37 KB, application/pdf)
2025-06-18 12:29 UTC, Armin Le Grand (allotropia)
Details
Output PDF after the fix. (22.11 KB, application/pdf)
2025-06-20 09:13 UTC, Jazevedo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jazevedo 2025-05-23 21:27:18 UTC
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
Comment 1 Jazevedo 2025-05-23 21:29:56 UTC
Created attachment 200937 [details]
The output PDF that fails to open
Comment 2 Jazevedo 2025-05-23 21:32:58 UTC
I made a mistake in the second step, what I meant was: 

Select: File > Export As > Export as PDF

Sorry for this mistake.
Comment 3 m_a_riosv 2025-05-23 21:56:43 UTC
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.
Comment 4 mikhail.machine 2025-05-26 06:51:26 UTC
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
Comment 5 Timur 2025-05-26 09:06:11 UTC
This is LO bug. Although some PDF readers still can open it, prevoiously all could and size is much bigger.
Comment 6 Alan B. 2025-05-26 09:16:53 UTC
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
Comment 7 Jazevedo 2025-05-27 13:34:40 UTC Comment hidden (obsolete)
Comment 8 Telesto 2025-05-28 19:25:02 UTC
(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
Comment 9 Armin Le Grand (allotropia) 2025-06-12 12:02:33 UTC
Taking a look...
Comment 10 Armin Le Grand (allotropia) 2025-06-12 12:26:05 UTC
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...
Comment 11 Armin Le Grand (allotropia) 2025-06-12 12:36:28 UTC
Created attachment 201224 [details]
Simplified BugDoc, draw, 1 object, pagesized, pattern 5%, 96% transparency

Seems to create same effect, PDF is ca. 4,7MB
Comment 12 Armin Le Grand (allotropia) 2025-06-12 12:38:00 UTC
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...
Comment 13 Armin Le Grand (allotropia) 2025-06-16 13:48:11 UTC
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...
Comment 14 Armin Le Grand (allotropia) 2025-06-16 18:03:33 UTC
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...
Comment 15 Armin Le Grand (allotropia) 2025-06-17 12:55:43 UTC
This (b) works in principle, not sure if to do only for PDF export, have to experiment on that one.
Comment 16 Armin Le Grand (allotropia) 2025-06-17 14:22:44 UTC
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...
Comment 17 Armin Le Grand (allotropia) 2025-06-17 19:04:46 UTC
Solution is on gerrit, see https://gerrit.libreoffice.org/c/core/+/186630
Comment 18 Commit Notification 2025-06-18 11:49:55 UTC
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.
Comment 19 Armin Le Grand (allotropia) 2025-06-18 12:29:09 UTC
Created attachment 201344 [details]
Result of PDF export using TransparencePrimitive2D
Comment 20 Armin Le Grand (allotropia) 2025-06-18 12:29:41 UTC
Created attachment 201345 [details]
Result of PDF export using UnifiedTransparencePrimitive2D
Comment 21 Armin Le Grand (allotropia) 2025-06-18 12:34:27 UTC
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 :-)
Comment 22 Armin Le Grand (allotropia) 2025-06-18 13:00:52 UTC
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...
Comment 23 Armin Le Grand (allotropia) 2025-06-18 13:09:33 UTC
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...
Comment 24 Miklos Vajna 2025-06-19 06:58:17 UTC
> 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.
Comment 25 Armin Le Grand (allotropia) 2025-06-19 15:30:56 UTC
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
Comment 26 Commit Notification 2025-06-19 17:41:08 UTC
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.
Comment 27 Jazevedo 2025-06-20 09:12:38 UTC
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
Comment 28 Jazevedo 2025-06-20 09:13:33 UTC
Created attachment 201374 [details]
Output PDF after the fix.
Comment 29 Commit Notification 2025-06-28 20:07:19 UTC
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.
Comment 30 Commit Notification 2025-06-28 20:07:22 UTC
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.