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

Re: Review of PPD File Structure Specification

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)?

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).

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.

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 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?

  "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: