Re: Review of PPD File Structure Specification
Henrique de Moraes Holschuh wrote:
On Sat, 04 Mar 2006, Henrique de Moraes Holschuh wrote:
On Sat, 04 Mar 2006, Pascal De Vuyst wrote:
Therefore I have reviewed this specification. It has been clarified in
many points and I took into consideration the comments I received before.
It can be found at: http://wiki.debian.org/PpdFileStructureSpecification
So far so good, but what should I do with the HPLIP PPDs that are
*postscript only* (and not hpijs-related)?
First off all thanks for considering my specification.
foomatic-db-hpijs for HPLIP project is maintained by Hewlett Packard in
linuxprinting.org CVS together with manufacturer provided postscript
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.
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.
hpijs-generator allows you to generate the xml foomatic database of ONLY
hpijs drivers.
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.
The xml foomatic database allows you to generate the PPDs for hpijs
ONLY, excluding real postscript PPDs.
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.
And off course the package hpijs_2.1.8+0.9.8 containing the binary parts
of the printer drivers.
Please choose the package names as you like, I was only giving examples
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.
This is important because newer PPDs will not necessarily work with
older versions of the binary hpijs drivers and vice versa because of
changed printer options. So downloading the latest hpijs PPDs from
linuxprinting.org is generally not a good idea in Debian.
I noticed there is actually a provision for true postscript PPDs, but only
for linuxprinting.org.
Shall I stop shipping HPLIP postscript PPDs? I can do that, they are
(supposedly) the same ones you get from linuxprinting.org, the difference is
just that they are PPDs officially supported by HP upstream (and, therefore,
by HPLIP).
As described Hewlett Packard maintains all off its real postscript PPDs
in linuxprinting.org CVS and includes these when generating a hplip source.
I think it is best not to ship the postscript PPDs in hplip-ppds and to
only include hpijs PPDs as described above.
Chris Lawrence has created a package linuxprinting.org-ppds containing
only real postscript PPDs from linuxprinting.org and this for different
manufacturers which (should) install into
/usr/share/ppds/linuxprinting.org-postscript. The HP PPDs included here
come from the same linuxprinting.org CVS and are in fact the same as in
hplip sources.
I can also ship them in a different directory
(/usr/share/ppd/hplip-postscript), but that will cause the usual PPD
duplication against PPDs in /usr/share/ppd/linuxprinting.org-postscript.
Please don't do this because as you indicate it will create duplicates.
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.
You mean a possibility for a sysadmin to override certain PPDs?
Please describe in more detail.
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, ...
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.
Regards,
Pascal
Reply to: