Printing from cupsd to cupsd via an internet link: Where the filters are applied

[Helge Blischke]

Sebastian James wrote:
> Hi CUPSers,
> 
> We've been using cups to print across a WAN link for quite a while now. It works well.
> 
> cupsd_1 receives a print job, then sends it using the https method over the WAN to cupsd_2 which then forwards it on to a printer.
> 
> If the incoming print job needs to be converted using the CUPS filtering system into a suitable format for the printer at the end of the chain, then the filtering HAS to happen at cupsd_1, as far as I can tell.
> 
> This is not always a good thing, because we generally end up transferring _more_ data across the link. For example, if the incoming job is a PDF file, then converting it into postscript suitable for an HP Laserjet printer leads to a _lot more_ data to transfer.
> 
> It seems that the ipp protocol or at least cups' implementation of it means that data that is sent via ipp or its encrypted version, https is considered "finished".
> 
> It would be great if it were possible to set a parameter in cupsd.conf to say "always apply file-typing heuristics and CUPS filtering to incoming jobs".
> 
> Would this feature be a major problem? I would like to implement it.
> 
> very best regards,
> 
> Seb James

I had a similar problem with my Mac OS X laptop which connects to my company's network via an
UMTS/HSPA link. As this suffers similarly from the size of the print kobs transferred,
I did the following workaround:
(1) I downloaded the fully configured PPD from the print server and installed
     the printer locally but using ipp://printserver/printers/printername as
     DEVICE_URI
(2) Then I deleted the /etc/cups/ppd/printername.ppd on the local machind
     and restarted the local CUPSD.

Thus I have a permanently installed printer which behaves exactly as
an imported printer (e.g. by CUPS browsing or polling).

I'd suggest to gibe that a try, especially as - provided your WAN link is up - you
even are able to administer the remote printer.

Helge

-- 
Helge Blischke
Softwareentwicklung

H.Blischke at acm.org