Re: Prebuilt ppd packages
Thanks you for commenting on my Specification, it motivated me to make
some changes to it.
The new Specification can be found at
http://wiki.debian.org/PpdFileStructureSpecification.
I've added my considerations below.
Roger Leigh wrote:
> Thanks for taking the time to write this. I've added a few comments
> below for your consideration and comment.
> > 2. This ppd directory should contain subdirectories according to the
> > "driver type":
> > /usr/share/ppd/gs for drivers common to all Ghostscripts (gs-esp,
> > gs-gpl and gs-afpl);
> > /usr/share/ppd/cups-raster for CUPS-only drivers;
> > /usr/share/ppd/ps-printer for drivers for PostScript printers.
> I don't agree with this (though I might be convinced otherwise). A
> PPD is a "Postscript Printer Description". That is, a definition of
> the capabilities of a PostScript printer.
> CUPS-only (cups-raster) PPDs, for example, are not proper PPDs,
> because they are describing a "pretend" PostScript printer to allow
> printing on a non-PostScript device. They are specific to CUPS, and
> as such, I don't think they should live outside /usr/share/cups/model.
I agree but cups-raster PPDs are still PPDs since they follow the PPD
Specification v4.3.
If I'm not mistaking gutenprint PPDs contain foomatic extensions
allowing them to be used by other spoolers than CUPS with foomatic-rip
so they are not specific to CUPS. A symlink from
/usr/share/cups/model/ppd to /usr/share/ppd is be enough to make all
PPDs avaiable to CUPS.
> Are there currently any PPDs for gs-(esp|gpl|afpl)?
This was expressed a little bit vaguely in my specification. I mean PPDs
that use Ghostscript binary drivers, as you know there are many (e.g.
HPIJS).
> The Foomatic PPDs are a little different, I think, because they are
> intended to work with multiple spoolers, and IIRC some are "genuine"
> PPDs.
Most non-postscript PPDs today are PPDs with foomatic extensions and can
be used with different spoolers.
> To summarise, I think /usr/share/ppd should be reserved for vendor
> PPDs for hardware PostScript printers. If they use extensions to tie
> into some other system, they belong with the system in question
> (possibly another directory in /usr/share).
I don't agree because the main idea of my Specification is to have all
PPDs in one common location and not scattered over different locations.
Currently a lot of non-PostScript PPDs are already located in
/usr/share/ppd by packages foomatic-filters-ppds and hplip-ppds.
> > 5. All ppds should be gzipped to reduce disk space usage.
> Are there any systems which can't handle this? Otherwise, it's good.
Standard tools in Debian can handle gzip compression without problems.
> > 7. Package names for prebuilt ppds should contain the "project
> > name" where they originate from.
> It might be useful to have a common naming scheme, such as foo-ppd,
> and possibly a package which depends upon them all, to make
> installation easier. Dependencies/Recommends/Suggests from spooler
> and driver packages should also be considered.
I totally agree with you but I have reconsidered this and left this out
of my (new) PPD File Structure Specification. This is not absolutely
necessary for my PPD File Structure Specification to succeed, but it
would be very nice. Naming of packages can be done from different
viewpoints. Therefore I think more investigation of current PPD related
packages should be done and this should be defined in a seperate
specification.
Pascal De Vuyst
Reply to: