Re: Review of PPD File Structure Specification

[Pascal De Vuyst <pascal.devuyst@gmail.com>]

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:
> > 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.
>
>   
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
> doesn't)...
>
>   
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,
Pascal