Synthetic "Alpha" and "All" channels from PDFRasterizer::RasterizeSeparations

Product: PDFNet SDK (C++)

Product Version: 9.2.0
(also relevant to the 9.3.0 / July 5th Windows release)

Please give a brief summary of your issue:
(Think of this as an email subject)
RasterizeSeparations / synthetic channels “All” and “Alpha”

Please describe your issue and provide steps to reproduce it:
(The more descriptive your answer, the faster we are able to help you)
I’m using PDFRasterizer::RasterizeSeparations (to accommodate a memory-constrained use case), and notice that the returned collection often include separations named “Alpha” and “All” despite those channels not existing in the PDF (i.e., they are not exposed by Acrobat DC’s ink manager, nor are they present in the set of channels returned from our previous rasterizer library). While the mere presence of those channels isn’t problematic, they seem to appear in indeterminate order. Alpha seems to appear immediately after the CMYK channels, but ‘All’ sometimes appears after ‘Alpha’, and sometimes at the end of the separations collection. Since I can’t guarantee that an actual ink isn’t named ‘Alpha’ or ‘All’, is there a way to 1) exclude those channels during rasterization, or 2) deterministically identify those channels by inspection, or 3) understand the rules for when and where those channels will be included in the returned separations collection so that I can heuristically exclude them?

Please provide a link to a minimal sample where the issue is reproducible:
I’ve encountered this with a number of documents using code equivalent to the following (apart from applying a scale factor to shrink the image for thumbnailing). I can provide a sample PDF upon request, but am unable to attach either PDF or ZIP files to this post.

PDFDoc separation_doc(filename);

PDFRasterizer pdftronRasterizer;
pdftronRasterizer.SetImageSmoothing(false, false);
pdftronRasterizer.SetThinLineAdjustment(false, true);

Page pg = separation_doc.GetPage(1);
const auto kDefaultPageBox = Page::e_crop;
Common::Matrix2D mtx = pg.GetDefaultMatrix(true, kDefaultPageBox);
auto dummySeps = pdftronRasterizer.RasterizeSeparations(pg, (int) page_w, (int) page_h, mtx, nullptr /* clip */, nullptr /* pbCancel */);

Thank you!

Could you please provide a PDF file that demonstrates this issue so we can review further?

Hi Ryan - I would be happy to do so, but am unable to attach PDFs to the posts (‘filetype not authorized’). Can you reach out to me via email?

Thank you!

Hi Ryan,
For expediency, I’ve shared a PDF from our FTP service to reproduce the issue:
The link will auto-expire in 7 days though - please feel free to reach out to me directly if you need other sample documents.

Thanks once again!
– Jeremy

Thank you for the clarification.

The All Separation is actually in the PDF file, so if you want to ignore that, then you could search for that particular Separation and skip the one named “All”.

As for Alpha, this channel is more informative than anything. All the information from the Alpha channel is already in contained in the other Separations. It is just provided for possible convenience.

So it appears in your case you want to ignore the Separations with the names “All” and “Alpha”

Thanks Ryan,
I appreciate the guidance. I may have been misled by Adobe Acrobat, which doesn’t list “All” in either the Ink Manager or Output Preview channel lists. However, I do not see “All” when I export a newly-created CMYK+S document as a PDF using Photoshop. Without knowing where the “All” channel is being defined in the art creation toolchain, I’ll just skip those channels by name as you’ve suggested.

Once again, much appreciated!
– Jeremy

It is object 63 used here


Which is a Form XObject Fm2 used by Form XObject Fm0 which is used on page 1.

However, it looks like its not actually used, as you can see the PNG is empty/blank.

You could check the output for each Separation by converting the PNG back to raw image data, and check if there are non-blank pixels, and if not then ignore that Separation.

Interesting! I have not yet used CosEdit, but this motivates me to dig in… Also, checking for an empty channel would be enough to satisfy my goal completely, and is simple to implement during rasterization… thanks again for the suggestion!