https://bugs.documentfoundation.org/show_bug.cgi?id=171484
Bug ID: 171484
Summary: PPTX → PDF export: RGBA PNG images with <a:clrChange>
are rendered as grayscale and clrChange transparency
is not applied
Product: LibreOffice
Version: 26.2.1.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Impress
Assignee: [email protected]
Reporter: [email protected]
Created attachment 206403
--> https://bugs.documentfoundation.org/attachment.cgi?id=206403&action=edit
lo_bug_reproducer.pptx — the minimal trigger file lo_bug_reproducer.pdf —
LibreOffice's broken output lo_bug_reproducer_expected.pdf — correct output
with clrChange applied
When exporting a PPTX to PDF (File > Export as PDF, or --convert-to pdf
headless),
RGBA PNG images that have an <a:clrChange> blip effect are affected by two
distinct
bugs:
BUG 1 — clrChange effect is silently ignored
The <a:clrChange> instruction (e.g., white → fully-transparent) is completely
discarded during PDF export. The exported PDF contains the original image with
its white background intact instead of the white pixels being made transparent.
The SMask (alpha channel) present in the PDF reflects the original PNG alpha,
not the result of applying the color replacement. The same image renders
correctly on the Impress canvas.
BUG 2 — RGBA PNG image exported as DeviceGray instead of DeviceRGB
Some RGBA PNG images that carry a <a:clrChange> element are written into the
PDF
as DeviceGray (grayscale) XObjects rather than DeviceRGB, causing total loss of
color information. This occurs inconsistently depending on the specific PNG: in
a test PPTX with two affected images on slides 27 and 41, one was exported as
DeviceRGB (wrong transparency, but color preserved) and the other as DeviceGray
(color completely lost). Without the <a:clrChange> element, the same RGBA PNGs
export with correct colorspace.
--- Steps to reproduce ---
1. Open the attached minimal reproducer PPTX (lo_bug_reproducer.pptx).
It contains one slide with a single RGBA PNG image (blue square on white
background) and the following blip markup:
<a:blip r:embed="rId1">
<a:clrChange>
<a:clrFrom><a:srgbClr val="FFFFFF"/></a:clrFrom>
<a:clrTo><a:srgbClr val="FFFFFF"><a:alpha
val="0"/></a:srgbClr></a:clrTo>
</a:clrChange>
</a:blip>
2. Export to PDF: File > Export as PDF > Export
(or: soffice --headless --convert-to pdf lo_bug_reproducer.pptx)
3. Open the resulting PDF.
--- Expected result ---
The blue square is visible on a transparent background (white pixels removed).
--- Actual result ---
Bug 1: The white background is retained — clrChange had no effect.
Bug 2: In real-world files, some affected images render as grayscale instead of
color (confirmed by inspecting /ColorSpace = /DeviceGray in PDF
XObjects).
--- Additional information ---
- Confirmed on LibreOffice 26.2.1.2 (macOS), both GUI export and headless
--convert-to pdf.
- The import-side rendering in Impress is correct; the bug is
PDF-export-specific.
- A workaround is to pre-process the PPTX: bake the color replacement into the
PNG pixels using Pillow and remove the <a:clrChange> XML node before passing
to LibreOffice for conversion.
- Related import-side bugs (not duplicates — those fix canvas rendering, not
PDF export): Bug 154880, Bug 149670, Bug 113163, Bug 119884.
- Searched Bugzilla: no existing report covers this specific PDF export
failure.
--
You are receiving this mail because:
You are the assignee for the bug.
