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

Re: Simplified PPD File Structure Specification

Hash: SHA1

Pascal De Vuyst <pascal.devuyst@gmail.com> writes:

> I have simplified the PPD File Structure Specification at
> http://wiki.debian.org/PpdFileStructureSpecification after comments
> from Roger Leigh, Henrique de Moraes Holschuh and Chris Lawrence in
> bugs reports and on mailing list. I've also added references and
> status of bug reports.
> I would like to thank you guys for contributing to this Specification.
> Following the spirit of this Specification should be an easy target now!
> As always comments and suggestions to the Specification are welcome.

I've just had a read through, and these are some further comments:

* I prefer /usr/share/postscript/ppd over /usr/share/ppd.
  - In the past, other Postscript-related things (such as postscript
    libraries) have been attempted to be packaged, but there is no
    standard location for them.  It would be nice to have this for
    future use.
  - This gives Postscript-related "stuff" a directory like for
    perl/python/other interpreted languages in /usr/share.

* 6. Inside the PPDs a *Manufacturer string should be contained
     according to the PPD specification (case-sensitive).
  - I would recommend here to use the capitalisation style used any
    PPD files from the vendor, for consistency.

* I'm still not satisfied that all PPDs should (or should not) go in
  the same place
  - I'd like to consider the use cases for each tool/server which uses
    PPD files.

  As an example: All the CUPS and LPRng queues which have a PPD
  associated with them provide a facility for getting the PPD for that
  queue (e.g. with lpc).  For CUPS, they are stored under
  /etc/cups/ppd/queuename.  These PPDs are copied from somewhere when
  the queue is set up, and the source PPDs are not required after this

  Therefore, the source PPDs are probably only needed by tools which
  are involved with queue setup.  Client applications (e.g. kprinter)
  will request the PPD directly from the printer daemon, which will
  not involve access to the original source PPDs under /usr/share/...

  So, it would be nice to get a complete list of all of the programs
  which do something with PPDs, and work out what the use cases of the
  PPD files are for each of them.

  Looking at the gutenprint PPDs, my concern is that they will be
  usable in ways which don't make sense, and will result in
  non-working setups.  They differ from normal PPDs with these lines:

    *cupsFilter:    "application/vnd.cups-raster 100 rastertogutenprint.5.0"
    *cupsFilter:    "application/vnd.cups-command 33 commandtoepson"

  This means that the PPD is useless unless used in conjuncation with
  CUPS, because this directs the cups-raster image to be processed
  with the "rastertogutenprint" filter.  As a result, it doesn't make
  sense to use with any other printing system.

  So, to summarise:
  - These PPDs are ultimately only useful when used by the CUPS
  - Other tools which create/modify CUPS print queues might
    legitimately need to work with them.
  - Those tools shouldn't allow them to be used with other print

  I'm not yet sure what the best solution is here, but I think we will
  get a better picture of how to organise things by considering how
  each tool will use the different types of PPD in greater detail.


- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>


Reply to: