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

Hermann Lauer hermann.lauer at iwr.uni-heidelberg.de
Thu Jul 15 15:34:22 PDT 2004


Hello Michael,
thanks for your quick resonse.

> Hermann Lauer wrote:
> > Dear list members,
> > 
> > while trying to print from Mac OSX 10.3 to a CUPS 1.1.20 server
> > (solaris machine) I stumbled over the following question:
> > 
> > If the mime type application/pdf is disabled on the solaris server
> > any pdf printed on the the MAC Client is rejected with a
> > document-format-not-supported by the solaris machine. The cupsd
> > on the mac received the available mime types of the solaris
> > machine correct, so
> > 
> > Why couldn't the local cupsd on the Mac filter the pdf to postcript
> > locally ? (which sould produce superior quality compared to the
> > xpdf conversion) 
> 
> That is questionable; I think Xpdf supports a superset of what the
> cgpdftops filter does...

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.

> 
> > I tried to search for such a solution, but up to now found no hint how
> > to enable such a feature in the local cupsd.
> > Please tell me if I overlooked something obvious.
> 
> We don't currently offer a generic solution for this; the PICT
> format is a special-case, and quite frankly we've never had anyone
> ask for this sort of functionality.

Somebody has to be the first to ask ;-)

> One issue with this is that the server may not support PostScript,
> and in order to support remote raster printers you start getting
> into a lot of rasterization and driver issues that are not easily
> solved.  Many filters produce printer-specific PostScript as well,
> so you'd be introducing potential problems there as well.

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.

Further arguments for this approach are:

1) Power users can install additional filters on their
   local machines

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.

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

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. 

> 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 ?).

> 
> In short, we aren't keen to implementing more filtering into the IPP
> backend since the potential gains are few and the potential for
> harm is great (think network bandwidth usage, uncontrolled resource
> usage on the local system, etc.)  PICT is and will always be a

As mentioned above, that depends on the power of the used machines
and the scaling you want to have. In my opinion it's better if
a user brings down his own machine with a bad document (pdf's
generated from word could grow unbelievable big) than the
spool server everybody depends on.

> special case, and its use will hopefully fade away now that Apple
> has deprecated it.

Hopefully I have given some arguments why I think the proposed functionality
would be a good thing.

Thanks for all your work on cups,

  greetings 
     Hermann

-- 
Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres 
Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg
IWR; INF 368; 69120 Heidelberg; Tel: (06221)54-8236 Fax: -5224
Email: Hermann.Lauer at iwr.uni-heidelberg.de





More information about the cups mailing list