PDF to PostScript Using Ghostscript: large files having issues printing

Question

I'm currently using Ghostscript to convert 500 page PDF files into PostScript.

I'm using Windows 7, Ghostscript x64 v 9.16, and a Kodak Digimaster Commercial Printer.

I use the following arguments for GhostScript to convert a PDF into PS:

C:\Program Files\gs\gs9.16\bin\gswin64c.exe" 
-dCompressFonts=true 
-dSubsetFonts=true 
-dEmbedAllFonts=true 
-sFONTPATH=C:\Windows\Fonts\ 
-dNOPAUSE 
-dBATCH 
-sDEVICE=ps2write 
-sOutputFile="PostScript.ps" 
"MyPdf.pdf"

I then add %KDK (proprietary) commands to dictate which pages need to print on which paper by using the %KDKSlip command based on the Printer documentation.

The example below would print all pages on Letter duplex except for pages 1/2 and 5/6. Pages 1/2 would print on a paper defined under the name of "YellowPerf", while 5/6 would print on "TriPerf":

 %!PS-Adobe-3.0
 %%BoundingBox: 0 0 612 792
 %%HiResBoundingBox: 0 0 612.00 792.00
 %%Creator: GPL Ghostscript 916 (ps2write)
 %%LanguageLevel: 2
 %%CreationDate: D:20150506143059-05'00'
 %%Pages: 8
 %%DocumentMedia: Letter 612 792 0 white ()
 %%+ YellowPerf 612 792 0 yellow ()
 %%+ TriPerf 612 792 0 white ()
 %KDKRequirements: duplex
 %KDKSlip: YellowPerf duplex 1
 %%+ TriPerf duplex 5
 %%EndComments
 %%BeginProlog

This is then sent to a Kodak Digimaster printer using a Windows command:

> COPY PostScript.ps PrinterName

This has worked fine with smaller documents, but I'm having issues with larger page sets.

When I attempted to print to the Digimaster using a 500 page PDF to Postscript file, it had errors occur: "Busy, do not reset the RIP".

File size of those that didn't work:

PostScript File Size: 52 MB
PDF File Size: 41 MB

File sizes of those that did work:

PostScript File Size 1MB
PDF File Size: .8 MB

Why does this work fine with smaller files but get hosed on larger files?

Would anyone have any advice?

Answer 1

It is not necessarily the filesize of the PostScript that causes your problem:

• It could be the PostScript itself, or
• it could be that you made a mistake with your editing of the PS files when you inserted the (proprietary) %KDK-comments.

Are you sure your text editor doesn't silently change your linefeed characters?! This could also change the binary parts of the PostScript!

Also, I'm not sure if the copy command does handle print jobs like it should. I would prefer the lpr command (ah... is that even still available on your version of Windows?!)

To debug this and to explore a few different roads to successful printing, I would try a few different steps:

To debug

• Send the original PostScript, without the added %%KDK DSC header comments, to the printer.

  That printer model has a nice feature you can utilize: you can check if its RIP processes the input file completely and successfully without needing to output your 500 pages on (wrong) paper and waste it therefore (you'd also need to discard it afterwards -- too much work too). Just click the red "Stop" button on its user interface monitor.

  Does that one complete the RIP process successfully?

  Yes? Now you can now even print it. Before you do so you can even modify the job settings to select a particular paper tray, by clicking on some button on the interface (can't recall the exact button label though). Then "release" the job and it will print.

  If it worked, you can again turn your attention to get your %%KDK lines right.

  If it didn't you have to try another route.

Check if a different PDF-to-PS converter is working

• Create a PostScript file with the help of pdftops (see here for the pdftops.exe version -- read the README to see which options are available).

  Proceed analog to above: first see if it completes the RIP process. Then continue with your %KDK manipulations....

Check if the direct PDF printing is working

• The Digimaster model can consume PDF directly. (Well, internally it uses its own PDF-to-PS converter, but that isn't visible to the outside -- so it doesn't really count as a PDF RIP...)

• If that works, you can even prepend your appropriate %KDK comments to the PDF file, similar to the lines below (don't rely on me getting the details right, it's from the top of my head, and memory is decades old!):

  %!PS-Adobe-3.0
  %%.........................
  %%DocumentMedia: ..........
  %KDKRequirements: .........
  %KDKInserts: ..............
  %KDKSlip: .................
  %KDKBody: .................
  %KDKCovers: ...............
  %KDKPDFPrintAnnotations: on 
  %KDKPDFFitToPage: on
  %KDKBinaryOK: on 
  <esc>%-12345X
  %%Emulation: pdf
  %PDF-1.5
  %...here follow the lines of the original PDF file...
  ...
  

Send jobs via "Kodak Printfile Downloader" (KPD)

• For Windows there used to be the so-called 'Kodak Print File Downloader' (KPD). The KPD is an application, not a printer driver. Not sure if it is still available.

• You could open its GUI, then load a PS, PDF, PCL or TIFF file into its to-be-printed-list of jobs. Then select a few job options (like trays, stapling, sorting etc.). Lastly, send the job off to the Digimaster...

• The KPD essentially does the same thing, as you want to achieve: insert %KDK commands into the file header. But you want to do it with a script or an editor (and possibly automatically via a batch process, once it works).

• The KPD requires interactive user activity and cannot be scripted.

• But you can (ab-)use it to intercept the files it creates from the Windows spooling system, study them and then adapt your scripted efforts so that they also work....

---

Update

^{(I had wanted to add this already in my initial answer. But time ran out, so I skipped it for the time being..)}

Observe the RIP processing directly at the printer UI

• Digimaster printers have their own built-in touchscreen or flatscreen or tube monitor (depending on the age of the model). They also typically have a full-time operator who knows the machine and its tweaks and peculiarities quite will. The machine may be quite a distance from the user sending a job.

• So the following should be done when debugging a print problem:

  • Ask the operator to set the printer to "stop printing", but still "receiving new jobs".
  • Submit any job(s) you want.
  • Walk up to the printer and its operator.
  • Release the job for RIP-ping and observe what happens:
    • You may see everything going alright and completing until the last page (you know how many pages you submitted, right?)
    • Or you may see the job aborting at a certain page number.
    • Or you may see the printer RIP chewing extremely long on a certain page (or several pages), but finally completing the job.
    • Or you may see the printer RIP hanging with a certain page forever.
    • Or...

  In any case, the details which are observable here may give important clues about where to look next...