I'm developing a "paperless" workflow and plan to save all files in PDF/A-1b format.

I'm trying to develop a simple batch file for converting PDF files that I create or receive to PDF/A-1b. Starting from this answer, I have the following batch file:

gswin32c ^
   -dPDFA ^
   -sProcessColorModel=DeviceCMYK ^
   -dUseCIEColor ^
   -sDEVICE=pdfwrite ^
   -o %2 ^
   -dPDFACompatibilityPolicy=1 ^
    "C:\Program Files (x86)\gs\gs9.07\mylib\PDFA_def.ps" ^

In PDFA_def.ps, I've tried a few different ICC profiles, including one I found on my system


and sRGB_IEC61966-2-1_no_black_scaling.icc from color.org.

My test input file is a 1-page email printed from Microsoft Outlook 2010 using CutePDF 2.8 (which uses Ghostscript 8.15).

After converting with my batch file and Ghostscript 9.07, Adobe Reader thinks the output is PDF/A, but PDF/A-1b validation by pdf-tools.com fails with the message "The value of the key N is 4 but must be 3."

I have traced this back to the following construct in the PDF output file:

/N 4/Length 2595>>stream

If I change /N 4 to /N 3, the "value of key N" message goes away. /N apparently represents the number of objects in the stream that follows this header. I don't know how to read the encoded stream so I don't understand what it contains nor why pdf-tools thinks it must only contain 3 objects.

A PDF/A printed using Bullzip, which also uses Ghostscript, also fails validation with the "key N is 4 but must be 3" message.

Does this have something to do with the color space? I'm out of my depth there. I think I'd be happy with a "plain" sRGB space. Ghostscipt docs say the PDF/A encoding must be CMYK. Adobe implies that either RGB or CMYK works for PDF/A. So I'm unclear about how to find an appropriate .icc profile.

Or maybe the validator is wrong and everything is fine?

2 Answers 2


With the help of a GhostScript developer in this bug report, I was able to solve the /N problem. Lessons learned:

  • The GhostScript doc referenced in my question is out of date. The current doc, here, says that ProcessColorModel=DeviceRGB is okay.
  • ICC profiles describe a color space. Some valid color spaces are GRAY, RGB, and CMYK. You can check the color space of an ICC profile using the free ICC Profile Inspector.
  • In the section of the PDF file causing validation errors, /N represents the number of colorants.
  • The PDFA_def.ps file emits the /N value. The sample included with Ghostscript 9.07 only emits /N 1 (for ProcessColorModel=DeviceGray) or /N 4 (for any other ProcessColorModel).
  • My original test specified ProcessColorModel=DeviceCMYK which caused /N 4, but used an ICC profile describing an RGB color space. The validators correctly caught this discrepancy: I promised 4 colors but only described 3.

Most ICC profiles that I found for displays and office printers describe an RGB color space. (CMYK seems more specific to high-end printing presses and certain kinds of paper.) For my purposes, RGB is preferable. The following batch file converts a PDF file to PDF/A-1b with an RGB color space:

gswin32c ^
   -dPDFA ^
   -sProcessColorModel=DeviceRGB ^
   -dUseCIEColor ^
   -sDEVICE=pdfwrite ^
   -o %2 ^
   -dPDFACompatibilityPolicy=1 ^
    "C:\Program Files (x86)\gs\gs9.07\mylib\PDFA_def.ps" ^

In PDFA_def.ps, specify an ICC profile that describes an RGB color space, and change the section for defining an ICC profile as follows:

% Define an ICC profile :

[/_objdef {icc_PDFA} /type /stream /OBJ pdfmark
[{icc_PDFA} <</N systemdict /ProcessColorModel get /DeviceGray eq {1} {systemdict /ProcessColorModel get /DeviceRGB eq {3} {4} ifelse} ifelse >> /PUT pdfmark
[{icc_PDFA} ICCProfile (r) file /PUT pdfmark

The long line includes a nested ifelse statement that will detect ProcessColorModel=DeviceRGB and emit the appropriate /N 3. The resulting file should pass validation at pdf-tools.com.

Update: I've created a somewhat more capable batch program and published it in a blog post: Batch Convert PDF to PDF/A.

  • I have just used pdf-tools and the only validation error I got was "The value of the key N is 4 but must be 3.". You can not imagine how happy I am to read your detailed answer here. Thanks a million. Mar 30, 2015 at 23:53

I would suggest to first re-test your problem on the latest version 9.07 of ghostscript, just in case this problem was already fixed.

If this doesn't help, it will take a real PDF guru to answer this problem. I suspect the problem has something to do with a conflict between the content of the .ps file and the parameters of the gswin32c command.

However, as the problematic file is generated by ghostscript, you have the right to post your question on the ghostscript Bugzilla page (registration required), where the developers will answer your question. If it is a bug in ghostscript, it will most probably be fixed in the next version.

In addition to the problem description as in your post, you should attach an example input .ps file and the resulting .pdf file. Try to minimize their sizes.

In the past I have reported several suspected ghostscript bugs on that forum and was always well-answered, and the real bugs I have found were all fixed.

  • Thanks for the reply. I may have confused things by mentioning that the the original was created by CutePDF 2.8, which uses GhostScript 8.15. However, the actual conversion that I'm trying to debug was done with GhostScript 9.07. I'm kind of surprised that PDF/A conversion hasn't been solved and verified already, but I haven't found a thorough tutorial. I may try the ghostscript forum.
    – Mark Berry
    Mar 30, 2013 at 15:42
  • Just remember that this is not a user-oriented forum but a bug report website, answered directly and only by the developers.
    – harrymc
    Mar 30, 2013 at 20:38
  • I decided, before submitting a bug, to download a trial of Adobe Acrobat XI. There, my test documents pass "pre-flight" PDF/A-1b validation. Does Ghostscript (and do others) tend to lean toward the Adobe interpretation of the standard? If so, there's probably no point in pursuing this as a bug.
    – Mark Berry
    Apr 2, 2013 at 2:58
  • According to what you say, products based on Ghostscript find this /N to be non-conforming. Acrobat's not detecting it can simply be a bug in the Acrobat checker. In my own reading of the PDF specs, I have not found /N in the list of legal parameters for FlateDecode, so I have no idea why it is being emitted at all (you can try to delete it and see if the pdf still works). You don't have to worry about presenting the Ghostscript developers with a false bug - I have already done so more than once and was always treated with courtesy.
    – harrymc
    Apr 2, 2013 at 6:12
  • I've created bugs.ghostscript.com/show_bug.cgi?id=693830. As best I can tell, /N is not a FlateDecode parameter; rather, "FlateDecode", "N", and "Length" all describe how the following "stream" is to be interpreted. The Acrobat "Internal PDF structure" tool shows that this object is under OutputIntents > 0 > DestOutputProfile and that the stream is an ICC Profile stream, but I'm still not clear on what the /N means.
    – Mark Berry
    Apr 2, 2013 at 19:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.