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

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: