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

Re: Simplified PPD File Structure Specification



On 1/18/06, Roger Leigh <rleigh@whinlatter.ukfsn.org> wrote:
> 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.

No argument here either way; whatever the consensus is, I'll adapt.

> * 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/...

On the other hand, some software (openoffice.org, notably) seems to
want the PPDs too, yet isn't involved in queue setup.

Other than "true" PostScript printer PPDs, some spooler interpretation
seems to be necessary (which, at some level, makes me wonder whether
PPDs for non-PostScript printers are a particularly good idea, even
though linuxprinting.org seems to be moving in that direction at the
expense of the foomatic printer XML database).  And PPDs seem to take
up a lot of dead space, hence why I explicitly discourage installing
the foomatic-filters-ppds package in favor of using the XML database
with foomatic-configure or a fancy front-end (foomatic-gui, printconf,
whatever).


Chris

Reply to: