[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Review of PPD File Structure Specification

Henrique de Moraes Holschuh schreef:
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 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.
You can read about this here:
look for "foomatic-db-hpijs source for 2.1.8" and the Re's.

Will do.

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, which
will work for anything and everything.

CUPS already does this, PPDs for installed printers are copied and modified under /etc/cups/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 other.

You *cannot* do that. Search for posts about bin­NMUs interating with strict
dependencies between arch-any and arch-all packages in d-devel.

But I have a half-assed solution that relax dependencies enough to at least
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 on the
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) where
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 opposed
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
hand-tweak them.

Note that it is not "override", as all PPD tools just grab them all even if
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 mentioned CUPS already does this under /etc/cups/ppd. Do you mean a more general approach for different print spooler under /etc/ppd ?
I am still not compressing the HPLIP PPDs, because to me it is not clear that all tools support compressed PPDs. Do we have any sort of data to back 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 interface,
allows selecting them...) ?  Does gimp?  Does HPLIP (no, it actually

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 /etc/cups/ppd. 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.
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.

Kind regards,

Reply to: