Print PDF direct to printer

Helge Blischke h.blischke at acm.org
Fri Nov 13 09:37:04 PST 2009


Christoph Litauer wrote:

> Helge Blischke schrieb:
>> Christoph Litauer wrote:
>> 
>>> Dear cups users,
>>>
>>> very often students complain about the time it takes to print some PDF
>>> documents to our (fast) printers. I tracked that down to the following
>>> situation:
>>> - the documents printed are pdf converted ppt files with transparent
>>> backgrounds or backgrounds with color gradients.
>>> - the students print 2- or 4-up.
>>> - they print from windows clients using the windows cups driver.
>>>
>>> Due to the fact that postscript isn't able to represent transparency or
>>> color gradients, the generated postscript code is 40 to 50 times as big
>>> as the pdf source. This postscript code is printed very slowly (up to
>>> several minutes per page).
>>> A workaround would be installing a PCL driver for theses printers. But
>>> the resulting pcl code is nearly as big as the postscript code. When the
>>> document is on the printer it is printed very fast, but the printing
>>> process on the windows client takes lots of time (10-20 sec./page). So
>>> this doesn't seem to be a sufficient solution.
>>>
>>> A better solution would be sending the PDF code directly to the printer
>>> as the printer is able to print pdf and does this very fast.
>>>
>>> I wonder wether it would be possible to get a (possibly generic) windows
>>> driver that doesn't convert the pdf documents to postscript or pcl.
>>> Instead it should modify the PDF code as to use some printer special
>>> features (input tray, duplex, color vs. greyscale etc.) and send pdf
>>> code to the cups server. Then it would be easy to configure cups to
>>> detect windows generated pdf code and send this code unmodified to the
>>> backend.
>>>
>> 
>> I'd sugest to install Peter Lerup's printfile on the windows boxes
>> (freeware) and configure that to pass through PDF files unmodified to the
>> cups server. Then insert into the PPDs of the rexpective PDF printers a
>> line
>> 
>> *cupsFilter: "application/pdf 0 -"
>> 
>> As for job attributes like n-up printing and the like, I suspect you need
>> to rely on printers which understand IPP. If your PDF printers require
>> some other type of job ticket, please tell more about them. You could
>> even contact me off the list at h dot blischke at acm dot org.
> 
> Helge,
> 
> thanks for this suggestion! But for our student PCs this is not an
> option, because I am not able to explain the usage of printFile to
> thousands of students. printFile would be nice if it installs itself as
> a (virtual) printer driver.
> 

Another workaround that came to my mind would be the following:

- On the cups server, define printer instances with the needed job
  attributes.
_ For each of these printer instances, set up a samba share acting as
  a "hot folder" where the Windows users can drop their PDFs into.
  Set up a script which catches files dropped in and prints them to
  the respective printer instance.

The catching script can either be actvated by a cron job (caution: you need 
to be sure the file is complete, i. e.. no longer used by anything else 
(tested e.g. using the fuser command)) or by a modified implementation of 
samba's magic script (in that case, ask me for how to hack samba for this).

Helge





More information about the cups mailing list