Re: Review of PPD File Structure Specification
Henrique de Moraes Holschuh schreef:
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, ...
On Tue, 07 Mar 2006, Pascal De Vuyst wrote:
files. The PPDs from HPLIP source are generated from linuxprinting.org
CVS on every new release. I tried to persuade HP to include the
foomatic-db-hpijs source files (especially hpijs-printermap and
hpijs-generator) into their HPLIP sources but have not received an
answer until now.
I can lend a hand on asking that of HPLIP upstream, but I will
*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 these benefits for a debian user are worth the added complexity.
CUPS already does this, PPDs for installed printers are copied and
modified under /etc/cups/ppd.
You can read about this here:
look for "foomatic-db-hpijs source for 2.1.8" and the Re's.
A package e.g. foomatic-xml-hpijs_2.1.8+0.9.8 could then be created for
GUI tools using foomatic xml files like foomatic-gui.
What use would that package have over hplip-ppds (which it looks like I
will rename to hpijs-ppds) ?
Whatever the printer setup gui tools do, they can do better by being
extended to be able to also copy-and-modify an already-generated PPD,
will work for anything and everything.
As mentioned CUPS already does this under /etc/cups/ppd. Do you mean a
more general approach for different print spooler under /etc/ppd ?
The xml foomatic database allows you to generate the PPDs for hpijs
ONLY, excluding real postscript PPDs.
find -type f ! -name '*-hpijs*' does that, too ;-)
A package e.g. hpijs-ppds_2.1.8+0.9.8 (the current hplip-ppds) could
then be easily created containing only hpijs PPDs.
Yes, I will probably rename the package. But I want to see the
linuxprinting.org packages hit the archive first.
above. The main thing is that all these packages should have the same
version number making sure binary drivers and PPDs match up with each
You *cannot* do that. Search for posts about binNMUs interating with
dependencies between arch-any and arch-all packages in d-devel.
But I have a half-assed solution that relax dependencies enough to at
avoid mixing different upstream releases of hpijs + its PPDs already
deployed, it is probably enough.
I think it is best not to ship the postscript PPDs in hplip-ppds and to
only include hpijs PPDs as described above.
Very well. I will do so.
Also, we should define right away that /etc/ppd is where
system-admin-supplied PPD files are placed, that they are to be
authoritative over /usr/share/ppd ones.
We have two ways to enable /etc/ppd:
1. Add a symlink /usr/share/ppd/system-local -> /etc/ppd
2. Define that all applications must look in there (CUPS, etc).
I think (2) is better. I also think this issue should be brought up
OSDL printing summit, next month in Atlanta/USA.
I don't quite understand what you are trying to say here.
I mean that we should have a configuration directory (i.e. under /etc)
the sysadmin can drop a PPD, and have the tools just find it.
No Debian user should ever be subject to adding crap under /usr (as
to /usr/local) because of a missing /etc directory, IMHO.
You mean a possibility for a sysadmin to override certain PPDs?
Please describe in more detail.
Yes. I do that with the HPLIP PPDs for my printers, for example. I
Note that it is not "override", as all PPD tools just grab them all
they have the exact name. But if a tool is going to give precendence to
PPDs from some place, it should be from /etc/ppd and not /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
files with ease and this saves a lot of diskspace.
After installing a printer in CUPS the PPDs are gunzipped and copied to
A lot of applications are settling on CUPS for printing and make use of
the PPDs in /etc/cups/ppd.
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.
I am still not compressing the HPLIP PPDs, because to me it is not
that all tools support compressed PPDs. Do we have any sort of data
it up that they at least *should* support compressed PPDs?
From nearly all Debian standard tools there exist a z-version allowing
direct use of gzipped files: eg. zcat, zless, zgrep, ...
Does CUPS use them directly in .gz format (i.e. show them on the
allows selecting them...) ? Does gimp? Does HPLIP (no, it actually
It is only meant for saving disk space, I don't see any problems with
tools or applications not being able to handle this in Debian. Correct
me if I'm wrong.
You can always zless or zcat them to /etc/ppd/your_printer_here.ppd, but
that certainly goes against what we are attempting to do.