Re: Review of PPD File Structure Specification
On Mon, 13 Mar 2006, Pascal De Vuyst wrote:
> >I can lend a hand on asking that of HPLIP upstream, but I will consider
> >it *very* carefully before I do that. I don't see which immediate
> >benefits we'd have over packaging the PPDs themselves, as the
> >intermediate formats are pretty much useless (right now).
> >
> >(I don't consider saving less than 20MB worth the added complexity, BTW).
> >
> I think GUI printer setup tools could have lots of benefits by using the
> xml database. There is less duplication inside the xml files:
> manufacturer names are unique, different printer drivers for the same
> model could be grouped together, ...
> I think these benefits for a debian user are worth the added complexity.
Well, if upstream ships it I will package it of course, but still if you
want me to try a hand at convincing them of the issue, point me to these
tools please. If it is just foomatic-gui, I don't think it warrants the
hassle at this time.
> CUPS already does this, PPDs for installed printers are copied and
> modified under /etc/cups/ppd.
This is interesting, but it is different from a local admin equivalent of
/usr/share/ppd...
CUPS would get files from /etc/ppd as well, and place them modified as it
sees fit into /etc/cups/ppd.
I am *not* taking a CUPS-centric view if I can help it, even if I do agree
that user-friendly printing's future is in the CUPS path. Debian is not
CUPS-only.
> >I mean that we should have a configuration directory (i.e. under /etc)
> >where the sysadmin can drop a PPD, and have the tools just find it.
[...]
> As mentioned CUPS already does this under /etc/cups/ppd. Do you mean a
> more general approach for different print spooler under /etc/ppd ?
Yes. One as general as /usr/share/ppd.
> As said the PPDs in /usr/share/ppd are mainly used by printer GUI setup
> tools like CUPS and gnome-cups-manager. These tools can handle gzipped
At least gimp and hplip needs access to the PPDs (HPLIP I can fix to be able
to read .gz files, and gimp needs a plugin to strip off the crap they have
in there and place a proper CUPS printing interface that groks things right,
maybe gutenprint can do it). Other applications might need to, as well.
Also, some spoolers allow one to point to a PPD file in the queue
description, and I don't recall reading anywhere that such PPDs could be
gzipped...
We *can* go through the approach that all PPD files should ship compressed,
and that if the user needs them uncompressed, he has to do it himself and
place the uncompressed PPD file in /etc/ppd for example. But do not do it
under the false impression that the user will never need to do exactly that.
Chances are that she will have to, for now.
> files with ease and this saves a lot of diskspace.
IMHO we'd be better off generating the *uncompressed* PPDs on the fly into
/etc/ppd/<vendor>, from compressed XML databases, tarballs, heuristics, or
whatever.
> After installing a printer in CUPS the PPDs are gunzipped and copied to
> /etc/cups/ppd.
CUPS is not the entire universe of spoolers in use.
> A lot of applications are settling on CUPS for printing and make use of
> the PPDs in /etc/cups/ppd.
Yes, which is good. Maybe someday CUPS *will* be the only client-side
printing system we have to care about, but that's not how it works right
now.
> Gimp, HPLIP and other non-CUPS applications should use the PPDs in
> /etc/cups/ppd so every application on the system uses the same PPD.
HPLIP really should do it, since it is CUPS-centric for most stuff. But it
*can't* do so before the CUPS queue is set up, so I will teach it to read
.gz files (probably at the expense of temp files and other crap that will
give me headaches to make it safe security-wise).
However no non-CUPS application should ever bother with anything inside
/etc/cups, make no mistake about it. /etc/cups is for CUPS-enabled
applications *only*. If something that goes into /etc/cups should be
always used even by non-CUPS applications, then it is being stored at the
wrong place.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: