Surfaced while acting on the Codex review of PR #554 (the comment on LoopLibCore/sources/pdfstandardconversion.cpp:528, "Flatten before the CMYK normalization pass"). Filed as a separate defect because fixing it is a behavioural change well beyond a review fix.
What the reviewer suggested, and why it is not enough
The suggestion was to run transparency flattening before PDFRgbToCmykFixup, because the flattener's non-spot path embeds its page raster as DeviceRGB and thereby reintroduces the colour space the CMYK pass had just removed.
Reordering is not sufficient: PDFRgbToCmykFixup deliberately refuses to convert RGB image XObjects.
LoopLibCore/sources/pdfrgbtocmykfixup.cpp:462-479 appends every image XObject whose /ColorSpace resolves to an RGB name (isRgbColorSpaceName, line 212) to report->unsupported with the reason "RGB image XObjects require image-sample conversion."PDFStandardConversion::preview() turns unsupported items into blockers, and apply() returns early when the colour result fails.- The flattener's non-spot path embeds exactly such a DeviceRGB page raster (
pdftransparencyflattener.cpp:384-416: renderer.toImage(...) then painter->drawImage(...)).
Net effect
- With today's order (CMYK, then flatten): a working postflight rejects the DeviceRGB candidate.
- With the proposed order (flatten, then CMYK): the CMYK pass fails first with "RGB image XObjects require image-sample conversion".
Neither order lets a PDF/X-1a conversion of a document containing live transparency succeed.
Scope options
- Implement image-sample conversion in
PDFRgbToCmykFixup (fill in the case its own message names). No API change, but it changes a central component's behaviour for every consumer — PdfTool color-conversion, PageMaster export, and the standard-conversion path.
- Make
PDFTransparencyFlattener emit CMYK page content when the target requires it. This changes the exported PDFTransparencyFlattenSettings (a protected interface), so it needs a contract decision first.
Status
Deferred out of PR #554 by decision. PR #554 carries a reply on the review comment pointing at this issue.
Surfaced while acting on the Codex review of PR #554 (the comment on
LoopLibCore/sources/pdfstandardconversion.cpp:528, "Flatten before the CMYK normalization pass"). Filed as a separate defect because fixing it is a behavioural change well beyond a review fix.What the reviewer suggested, and why it is not enough
The suggestion was to run transparency flattening before
PDFRgbToCmykFixup, because the flattener's non-spot path embeds its page raster as DeviceRGB and thereby reintroduces the colour space the CMYK pass had just removed.Reordering is not sufficient:
PDFRgbToCmykFixupdeliberately refuses to convert RGB image XObjects.LoopLibCore/sources/pdfrgbtocmykfixup.cpp:462-479appends every image XObject whose/ColorSpaceresolves to an RGB name (isRgbColorSpaceName, line 212) toreport->unsupportedwith the reason"RGB image XObjects require image-sample conversion."PDFStandardConversion::preview()turns unsupported items into blockers, andapply()returns early when the colour result fails.pdftransparencyflattener.cpp:384-416:renderer.toImage(...)thenpainter->drawImage(...)).Net effect
Neither order lets a PDF/X-1a conversion of a document containing live transparency succeed.
Scope options
PDFRgbToCmykFixup(fill in the case its own message names). No API change, but it changes a central component's behaviour for every consumer — PdfToolcolor-conversion, PageMaster export, and the standard-conversion path.PDFTransparencyFlatteneremit CMYK page content when the target requires it. This changes the exportedPDFTransparencyFlattenSettings(a protected interface), so it needs a contract decision first.Status
Deferred out of PR #554 by decision. PR #554 carries a reply on the review comment pointing at this issue.