[cups.general] Re: local filtering for remote unknown mime types

[Michael Sweet]

Hermann Lauer wrote:
> ...
> That sounds to good - are there no problems with exotic fonts
> and exotic encodings ? As I have no (and don't want to have) control over the
> macs they have a rater unique font collections on them. After a quick look
> into cgpdftops it looks like this invokes the MacOS X print engine.

The only limitations in Xpdf that I am aware of are some of the
transparency and shaded fill operators; the fill operators are
fully implemented in the CUPS 1.2 version of pdftops, and Derek
(the author of Xpdf) is working on the transparency support now.
Fonts are fully supported as of CUPS 1.1.19.

The cgpdftops filter supports PDF 1.3, the Xpdf-based pdftops
supports PDF 1.5.

> ...
> Of course the algorithm should check the available mime types 
> (which are asked already) and
> decide based on the cost which way to take - just the same
> way it will do with a local printer.

However, there is 1) no way at present to support the FilterLimit
option properly, 2) it may not be possible to convert the file
to a printable format (e.g. a device or server may advertise
application/postscript but not application/vnd.cups-postscript,
making it impossible to print certain file types), 3) you will
lose functionality in the process (no page accounting, certain
limitations WRT raster printing, etc.), and 4) more than likely
you will use a lot of extra RAM, CPU, disk space, and network
bandwidth.

In short, it isn't a good idea for most environments, and we
are not willing to implement it.  If you want this functionality,
set the printer up locally on the client and send raw print data
to the server.

> Further arguments for this approach are:
> 
> 1) Power users can install additional filters on their
>    local machines

They can still do that with the current implementation, you just
setup a local driver.

> 2) Computing power for filters can be distributed. Here for example
>    the cups spooler is a rather old machine, while the client
>    machines are usually much more powerfull.

See my answer to #1.

>    Or think about a home network, where the printers
>    are attached to old slow desktop machines and
>    laptops are connected via LAN.

Actually, I'd expect the usual setup to have the printer on the
network - many network hubs have printer ports on them these
days, and there are even printers with built-in wireless
adapters (I have one at home...)

> 3) The spooler must have always the newest version of a filter with
>    the current approach, which could be a big problem if the
>    (often free) implementation lags behind the programs available
>    on the client machines. 

That's an administration problem, and you can bypass this via my
answer to #1.

>>In addition, CUPS 1.2 passes ALL files in a job to the remote server
>>in one call (this particular code isn't commited yet, as we are
>>working out some kinks) so adding more logic would bloat the IPP
>>backend even further.
> 
> 
> I don't think the ipp backend is the right place for this, it
> should be done at the same place as the filtering
> for local printers (thats done from the scheduler ?).

Well then, you are setting up a local print queue.  The CUPS
server does not talk to the remote IPP server directly, so it
has no concept of the supported MIME types on the remote server.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Printing Software for UNIX                       http://www.easysw.com