Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: David Chappell <David.Chappell@mail.cc.trincoll.edu> Date: Fri, 29 Mar 2002 17:01:41 -0500 Subject: Re: PPR: ppr-gs What are the advantages/tradeoffs? John Seifarth wrote: > The README.txt file in the ppr-gs-0.9 directory contains a rather > ominous warning: > "Understand that the resulting Ghostscript will have tempfile security > problems" I think it is a garbled remnant of a reference to the fact that Ghostscript might use mktemp(). Looking at gp_unifs.c (one of the files which I list as modfied), it seems that I changed it to use mkstemp() instead. Perhaps I meant to say that one can switch it back to mktemp() if one's system doesn't have mkstemp(), but that the resulting Ghostscript will have tempfile security problems. > Could you elaborate slightly? Could you please summarize what's going > on with Gostscript / PPR integration? PPR has worked fine for me for > years using the built-in gs executable in my Slackware distributions. > Why might I want to use ppr-gs? Will it become more important in the > future? I noticed a highlight in the 1.50a1 release announcement is > "improved Ghostscript integration". Does that require ppr-gs? Sure. Up to now PPR has used Ghostscript by means of special interface scripts with names begining with "gs*". These scripts call Ghostscript and use a real interface program to send the data to the printer. It worked, this approach had a number of problems. One was that it was necessary to shut the whole thing down (disconnecting from the printer) in order to do a job break (such as between the job and banner or trailer pages or between multiple copies printed by sending the job repeatedly). Another problem was that PJL couldn't be used to get printer status and pages counts because it would be intercepted by Ghostscript. Finally, communicating interface error codes back to pprdrv with Ghostscript in between was rather messy. In version 1.44 I did some pretty extensive rewriting of pprdrv so that it could take care of passing the data through Ghostscript rather than expecting the interface to do it. This code is a little rough in 1.44, but it works well in 1.50a1. One can enable it by either using one of the Ghostscript PPD files in 1.50a1 or by using the "ppad rip" command. The Ghostscript PPD files in version 1.44 have the line that would automatically activate the new Ghostscript handling commented out. This new Ghostscript integration means that pprdrv can send PJL directly to the printer. It can also start a new Ghostscript without closing the interface program and thus disconnecting. And means that pprdrv can more readily distinguish between problems with the interface program and problems with Ghostscript and it can report their status separately. Additionaly, getting rid of the gs* interfaces has reduced the clutter in the web interface. I also think that requiring the user to choose a different interface program if the printer required Ghostscript confusingly merged two completely different concepts. Not only that, but defering the decision about whether to use Ghostscript until after an interface has been chosen will make it possible to contact the printer and ask it for its make and model. This furthurs my goal of adding automatical printer identification to PPR. Finally, a special line the PPD file can tell PPR to use Ghostscript. Thus the user need only select the correct PPD file. And that brings up a future direction. I hope to use foomatic (http://www.linuxprinting.org/) to generate a set of PPD files with that additional line that tells pprdrv to use Ghostscript and what options to select. PPR-GS is just a distribution of Ghostscript adapted to the needs of PPR users. It was inspired by the ESP Ghostscript distribution (which hasn't been updated recently). It has 3rd party drivers. It is configured to enable every printer driver that would build. It is configured not to include X11 drivers (which pull in additional libraries). It omits PDF support on both input and output. It has a small patch to trap the special output file name "| >cat >&3" and send the printer output to file descriptor 3 (with using an actual instance of cat). So yes, you can continue to use the Ghostscript that comes with your distribution. The new integration fully supports this. But the PPR-GS distribution has additional drivers and is built without most non-printer drivers. And in the future it will come with a large set of PPD files that will match the drivers it will contain. - -- ================================================================ David Chappell David.Chappell@Mail.Trincoll.Edu Computing Center Postmaster@Mail.Trincoll.Edu Trinity College (860) 297-2114 Hartford, Connecticut 06106 U.S.A.