The customer reports and I've verified that the following command generates an entirely black output PDF file: bin/gs -dPDFA -dUseCIEColor -sDEVICE=pdfwrite -dPDFACompatibilityPolicy=2 -r600 -o out.pdf pptx.pdf
This is a regression, the first version which exhibits this behavior is: commit 9d37cdcdbcb3b3bb23d0eab06d1683735303d5e1 Author: Michael Vrhel <michael.vrhel@artifex.com> Date: Thu Jul 21 21:50:59 2011 -0700 Fix for bug 692364 in which we were were not handing the initial DeviceGray profiles correctly When the graphic state is started, the color spaces are first set to DeviceGray. In certain documents this is then the color space that is used for drawing and in fact the erase page will initially occur with this color space. If I have a destination ICC profile like CIELAB, then this is a problem since we will end up mapping DeviceGray to RGB with the old procedures giving us a CIELAB value of [255 255 255] which is a very bright red. With this fix we in the DeviceGray mapping we fix the colorspace to be ICC based and pass then handle the procedure with the ICC mapping. A minor fix was also needed in the pdf14device put_image where we use a DeviceGray color space, which happens to have an ICC profile. We now correctly create the ICC profile. Note that this will cause significant diffs in the cluster push as DeviceGray colors that were mapped to pure K before for a CMYK device (due to the fact that we were not installing the proper color space) will now map to composite black. This issue will be addressed shortly by another commit where we by default map all DeviceGray colors to K only in the CMYK devices.
*** Bug 692613 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > This is a regression, the first version which exhibits this behavior is: I think the problem is that the file contains transparency, the whole page is (unnecessarily I think) defined in a transparency group. PDF/A-1 does not permit the presence of transparency, so the content is rendered to an image. This is why the output file is very large. If the transparency group is as I think not required, then the customer may want to open a bug report with the creator of the PDF file. Adding transparency when it is not required seriously impacts performance and can lead to this kind of problem. There are I think several outstanding bug reports indicating that this has recently ceased working properly under some conditions and I think this is another of the same. The problem seems to be a duplicate of #692613, and probably has the same cause, the Range array in the ICCBased colour space has ridiculous values: /Range[0 0 0 0 0 0] Michael: I'm not sure if this is your province or mine now, I'll try and figure out where the bogus Range is coming from and I'll post here if I find out more.
In gdev_pdf_begin_typed_image, called from pdf14_put_image we find the colour space of the image from the 'pic' image common type by appropriate casting. The space is (as expected) an ICCBased space, and the cmm_icc_profile_data->Range->ranges[0].min and .max are both 0. This is true for all the entries in 'ranges'. Since this is what pdfwrite uses to write the Range information for the image this is why we get a bogus set of values. Hopefully Michael can take it from here, I'm not at all sure where the colour space is created....
Thanks Ken. That narrows this down a lot.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=224672fa4af11c4723c38ea11b4d51503a96f609 Thanks to Ken for doing all the up front work on this.