[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