Re: Simplified PPD File Structure Specification
-----BEGIN PGP SIGNED MESSAGE-----
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
point.
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
server.
- 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
daemons.
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.
Regards,
Roger
- --
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDzpNZVcFcaSW/uEgRAlRkAJ0XT9F6GJWkBE/8SLR43mblqUq0kwCgsGaK
9E9ynSHJvSOz8XGPJ4X2Bzk=
=nS8/
-----END PGP SIGNATURE-----
Reply to: