Re: Review of PPD File Structure Specification
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).
> You can read about this here:
> http://www.linuxprinting.org/forums.cgi?group=linuxprinting.foomatic.devel,
> 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.
> 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 binNMUs 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.
> >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
doesn't)...
> 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.
--
"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: