Feasability of adding PDF/X support, exporting "sRGB objects" in PDF

[Thierry Seegers]

Hi all,

I'm exploring the possibility of adding some form of PDF/X support when exporting to PDF.

Quickly explained, PDF/X is like PDF/A but for intended for physical printing. As such, many requirements are similar but with one notable difference: the output intent must carry a color profile of class "Output", read "an actual printer that wants CMYK information". As such, the color profile in the PDF's output intents must be in the CMYK color space as opposed to PDF/A which allows an sRGB color space.

I've been able to add all the other little details of PDF/X support to Skia except for that doozy. I'm by no mean a PDF expert, nor a color space expert and so I'm facing a real challenge. I don't know how feasible that task even is.

All I know that may make my day better is that PDF/X-4 "supports sRGB objects". Well, a quick and "for fun" experiment of literally replacing all five instances of the hard-coded string "DeviceRGB" in various "SkPDF*.cpp" files produced an unusable file: Apple's preview showed way off-base colors (as in, yellow became cyan) and Adobe Acrobat flat out refused to open the file showing a cryptic error. I'm not surprised by the result.

At this point my question is how feasible is finishing up this task of supporting PDF/X export given this requirement of "all objects in the PDF document can be described in the sRGB color space"? Is it...

...a minor task? I.e. All functions I need exist somewhere, it's a matter of lightly gluing them together and massaging a bit of existing code.
...a major task? I.e. Not all functions I need exist, new color-space-related code must be written and it's best if it's done by somebody who really knows this stuff.
...a daunting task? I.e. a fair chunk of SkPDF*.cpp files would have to be restructured (in addition to the above).

Thanks for any input or insights you can give me!

[K. Moon]

CMYK (as you might expect) is a 4 channel color space, while sRGB is 3 channel. At a minimum, all image data needs to be converted from 3 RGB channels to the 4 CMYK channels, before you can even think about changing the color spaces in the PDF.

Trying to interpret RGB data as CMYK is why you're getting all sorts of weird colors when viewing these PDFs.

--
You received this message because you are subscribed to the Google Groups "skia-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/623bf635-fc68-4bb7-8f7d-feca864214a4n%40googlegroups.com.

[Thierry Seegers]

To clarify, PDF/X-4 allows "sRGB objects" even if the output intent is in CMYK color. The experiment I did was to naively change the hard-coded string "DeviceRGB" to "sRGB" thinking the colors would be "off" but not necessarily wildly off.

The question is more about how to make SkPDF support the export of objects in "sRGB" color space rather than "DeviceRGB" color space.

You received this message because you are subscribed to a topic in the Google Groups "skia-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/skia-discuss/ze7IAEH5YkA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to skia-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CACwGi-6UD14%3D7Ui6kWfKjLRBWjE_P%3DTuqb00601kxoH6XrzrXA%40mail.gmail.com.

[K. Moon]

Thanks for the clarification. I only have a copy of ISO 32000, not the PDF/X or PDF/A specs, but I'm not aware of any such thing as an "sRGB" color space in the PDF format.

What PDF does support is "ICCBased" (managed color profile) color spaces. The standard specified this is the only way to accurately specify sRGB color; you can't just change the color space name to "sRGB."

As far as making your modifications, you probably want to look at SkPDFBitmap.cpp. It looks like this code already has support for writing out ICC profiles if proper color space information is provided to Skia, although I'm not sure whether or not it will work for your purposes as-is.

To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CACBa5Lsb1JkS_GF2LumSLFXBrxVSZGOSy%3DawXWeta3%2Bsk2kOsQ%40mail.gmail.com.

[Ben Wagner]

Skia just began putting the color spaces from SkImages into PDFs [0]
which should end up in the next Skia branch. So if you use high enough
resolution images and tag them with their color space, things may be
mostly PDF/X-4 compatible with very new Skia. That being said, at the
moment PDF/X conformity isn't really an objective, though Skia is
interested in making things more correct generally (like getting the
color spaces into the PDF). So if there is some specific PDF/X
required behavior that Skia really should implement anyway (would be
of benefit to users other than just checking a compatibility box, like
emitting a PDF/X tag) we would be interested to know what could be
improved. In particular it looks like unless one sets
SkPDF::Metadata::fPDFA one won't get any /OutputIntents which is
required with PDF/X, and at the moment that is hard coded to an sRGB
ICC profile (instead of allowing a color space to be supplied by the
user).

[0] https://skia.googlesource.com/skia/+/eff8181a629035377ad4e74c24aa250d4c095a90

> To view this discussion on the web visit https://groups.google.com/d/msgid/skia-discuss/CACwGi-5e27dXUC9tCc_gnF5qwXP_4tWLWnkgk4N4aCGmeY0bNQ%40mail.gmail.com.

[Thierry Seegers]

Thanks for the follow-up,

Indeed, support for PDF/X requires just a few more tags/metadata beyond what PDF/A requires but it also involves setting a color profile as output intent which, as far as I can tell, must be in CMYK and, therefore, would weigh at least 2.5MB. Even hard-coding a default sounds unreasonable. Attaching color space information to images (even if they're all sRGB) would also be necessary so doing it is a step towards supporting PDF/X output. But, and I may be mistaken here, I think one other thing that is also required is that colors like flat colors or gradients or anything described with a default of "DeviceRGB" color space now would have to be described with "DeviceCMYK". If that's true, that sounds like we're entering "explicit non-goal" territory as far as the Skia project is concerned.

Now, again, I'm no PDF nor color space expert so sorry if I'm rambling.

[Cristiano Carvalheiro]

@Thierry Sorry for digging this up, but did you manage to find a solution to produce valid PDF/X files in CMYK? I'm in a similar situation to what you described and looking for approaches on how to achieve that in Skia.

Thanks in advance.

[Thierry Seegers]

@cristiano

Unfortunately, we have not progressed further in adding support for PDF/X output. I don't know if you've considered it, but an option might be to integrate PDFLib into your product to convert a PDF produced by Skia to a PDF/X. Now, PDFLib is not free (as in beer), and it's not a lightweight library, but it might be the fastest and smoothest path to your goal.

[Cristiano Carvalheiro]

@thierry We are currently in the process of evaluating alternatives. Thank you for the tip.