I have several large PDF reports (>500 pages) with a form overlay containing grid lines and background shading that I converted from postscript using GhostScript's ps2pdf in a batch process. The PDFs that get created look perfect in the Adobe Reader. However, when I go to print the PDF from Adobe Reader I get about 4-5 ppm from our Dell laser printer with long, 10+ second pauses between each page. The same report PDF generated from another proprietary process (not GhostScript) yeilds a fast 25+ ppm on the same printer. The PDF file sizes on both are nearly the same at around 1.5 MB each, but when I print both versions of the PDF to file (i.e. postscript), the GhostScript generated PDF postscript output is about 5 times larger than that of the other (2.7 mil lines vs 675K) or 48 MB vs 9 MB. Looking at the GhostScript output, I see that the background pattern for the grid lines/shading (referenced by "/PatternType1" tag) is defined many thousands of times throughout the file, where it is only defined once in the other PDF output. I believe this constant re-defining of the background pattern is what is bogging down the printer. Attached are samples of my inputs and outputs
*** Bug 693195 has been marked as a duplicate of this bug. ***
*** Bug 693194 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Attached are samples of my inputs and outputs Sample files not attached to this report (or either of the 2 duplicates) I really need these. In addition teh command line being used with Ghostscript might be essential.
I tried attaching the files, but the page did not update. I'll try it again with the other info you requested and hope it does not generate a duplicate.
Created attachment 8769 [details] Input postscript file for PS2PDF
Created attachment 8770 [details] PS2PDF generated output PDF
When you print the test.pdf file from Adobe Reader (tested v8 & v10), you will see that even with a small report the print takes several seconds per page. This happens from several different PC's and printers.
Created attachment 8771 [details] PS2PDF command script no other PS2PDF library files have been changed. I call the process as described in the documentation: ps2pdf [input.ps] [output.pdf]
This bug is a duplicate of #691202 and possibly #687561. The job defines a form and almost the entire content of each page is the content of the form (this is a rare example of sensible form use). Because the form also includes a Pattern definition, and pdfwrite unrolls the form each time it is used, the output is significantly larger. The only way to resolve this is indeed to preserve forms. Since there is already an open enhancement, closing this as a duplicate. *** This bug has been marked as a duplicate of bug 691202 ***
Is there a workaround that we can try in the meantime while we wait for a fix? If we converted the form to a pattern, background image/watermark, could/would we alleviate the problem with the duplicating forms and speed up the printing? We are in a bind here and would appreciate any help or direction. Thanks.
(In reply to comment #10) > Is there a workaround that we can try in the meantime while we wait for a fix? Don't use forms ? > If we converted the form to a pattern, background image/watermark, could/would > we alleviate the problem with the duplicating forms and speed up the printing? Seems doubtful to me but you could try. All that happens is that the converted object ends up being written multiple times, whereas currently the form marking operations get written multiple times. Doesn't seem likely that anything will make much of a difference, but I could be wrong. Depends to some extent on your printer. Have you tried removing the pattern definition from the form, as I suggested in comment #9 ?
(In reply to comment #11) > Have you tried removing the pattern definition from the form, as I suggested in > comment #9 ? Actually I see I didn't suggest it, I meant to. Take it as a suggestion now :-) Instead of defining the pattern colour space in the form, define it outside the form, that *might* allow pdfwrite to spot the pattern reuse, and emit only one pattern definition.
Ok, I'll give it a shot. Could you by chance point me to an example showing where you can define/include outside objects via the GhostScript command line? I'll Google it anyway, but if you know of one right off it would be greatly appreciated. I apologize, I'm not a PostScript programmer by any means, but have been tasked to make this work, so forgive me as I struggle through this. One odd thing to note, my supervisor was able to pull up the PostScript in question using both GhostView and Adobe Distiller X, then print using the "PrePress" option and the printing is fast at 1 sheet per 1 to 1.5 seconds. What is different in the rendering/printing between GhostView and GhostScript? Is GhostView completely separate from GhostScript? Again, thanks for your help.
(In reply to comment #13) > Ok, I'll give it a shot. Could you by chance point me to an example showing > where you can define/include outside objects via the GhostScript command line? You can add aribtrary PostScript on the command line to Ghostscript by using the -f flag as documented in ghopstpdl/gs/doc/use.htm However I am suggesting that you need to change the nature of the PostScript you are sending to GS. Remove the Pattern colour space definition from the Form definition. Define the Pattern colour outside the form and reference the space from the form, rather than defining it there. > One odd thing to note, my supervisor was able to pull up the PostScript in > question using both GhostView and Adobe Distiller X, then print using the > "PrePress" option and the printing is fast at 1 sheet per 1 to 1.5 seconds. > > What is different in the rendering/printing between GhostView and GhostScript? > Is GhostView completely separate from GhostScript? Ghostview uses Ghostscript, but is a product of Ghostgum Pty. Given that you are complaining that printing the *PDF* file produced by pdfwrite, its not surprising that the the PostScripr prints quickly from Ghostview, siince this still has a form definition. As mentioned either here or in one of the duplicate bugs, Distiller *does* preserve forms in the PostScript as forms in teh PDF, we don't. So converting via Distiller will give a different result.
Command line PostScript follows a '-c' option. I recommend putting the PostScript in " " to help avoid shell character problems with characters like ( ) << >> Then you must use '-f' prior to the input file to terminate the -c processing. Complex PS is best put in a file and then just put the file name before the input file.
>However I am suggesting that you need to change the nature of the PostScript >you are sending to GS. Remove the Pattern colour space definition from the Form >definition. Define the Pattern colour outside the form and reference the space >from the form, rather than defining it there. Thanks, I figured out what you meant after reading through your post again. I was able to externalize the pattern defs from the form, but unfortunately the result was still the same.