Any comments or suggestions to this Specification are welcome!!! ?BR Please openly discuss this on [http://lists.debian.org/debian-printing/ debian-printing mailing list].

PPD File Structure Specification

Created: 05/01/2006 by ?PascalDeVuyst ?BR Last update: 07/08/2006 ?BR Contributors: RogerLeigh, ?Hmh, ChrisLawrence and ?MartinPitt ?BR When writing this specification the ?PrintingFilesystem Specification has been taken into consideration.

Introduction

There are several packages in Debian that provide prebuilt Postscript Printer Descriptions (["PPD"]s) for PostScript and non-PostScript printers. These packages should cooperate to form a single database of unique PPDs. This allows GUI printer queue setup tools like CUPS "Add Printer" web interface, gnome-cups-manager and foomatic-gui to provide users a printer model list so they can easily add their printers.

Packages in Debian that provide prebuilt PPDs

This specification affects the following packages:

Design

The main idea is to have the following file structure to make it possible for printer queue setup tools to locate the PPDs they are interested in: ?BR common_directory/printer_driver_type/upstream_reference/[further_classification/]filename.ppd

  1. The database of PPDs should be located in a common directory.
  2. The PPDs should be seperated by printer driver type. This allows printer queue setup tools to include only the drivers they are interested in.
  3. To avoid possible filename clashes between different packages providing PPDs and to easily seperate PPDs from different sources there should be a further classification refering to the "upstream project" where the PPDs come from and where they were created for.
  4. An optional further classification of PPDs is possible under "upstream_reference".
  5. The database is formed by several packages which provide PPD files inside this structure and it is not necessary to install all off these packages.
  6. Two seperate packages should not provide the same PPDs to avoid duplicate printer model entries in GUI tools.

Implementation

  1. PPDs should be located in /usr/share according to the Filesystem Hierarchy Standard because they contain static and arch-independent information.
  2. As common directory /usr/share/ppd/ should be used.

  3. The ppd directory should contain subdirectories that indicate the printer driver type. We should have the following classification:
    • /usr/share/ppd/cups-raster/ for PPDs for CUPS rasterto binary drivers that only work with CUPS.

    • /usr/share/ppd/foomatic-rip/ for PPDs for Ghostscript builtin and filter drivers that work with any spooler because they use foomatic-rip

    • /usr/share/ppd/postscript/ for PPDs for real PostScript printers.

    This allows GUI printer queue setup tools like foomatic-gui to extract manufacturer, model and driver information from PPDs found in /usr/share/ppd/cups-raster/ for configuring printers that use CUPS rasterto drivers and use information from foomatic-db to generate PPDs for configuring printer drivers that use Foomatic.
  4. Then a further classification refering to the name of the "upstream project" where the PPDs come from and where they were created for is necessary. I believe this to be the best classification:
    • Under /usr/share/ppd/cups-raster/:
      • cups-included for non-PostScript PPDs that use rasterto binary CUPS drivers and are included with CUPS;

      • gutenprint-5.0.0 for non-PostScript PPDs that use rastertogutenprint.5.0 binary CUPS driver;

      • Other "upstream references" for non-PostScript PPDs that use CUPS rasterto drivers that are not yet included into Debian. More and more printer manufacturers (will) provide CUPS rasterto drivers.

    • Under /usr/share/ppd/foomatic-rip/:
      • linuxprinting.org-gs-builtin for non-PostScript PPDs from linuxprinting.org's foomatic-db that can be used with binary printer drivers built into GPL or ESP Ghostscript;

      • foo2zjs, pnm2ppa, min12xxw, c2050, cjet, ... for PPDs for filters that make use of Ghostscript to provide a printer independent raster format like pbm;

      • hpijs for non-PostScript PPDs from HPLIP project.

    • Under /usr/share/ppd/postscript/:
      • linuxprinting.org for real PPDs for PostScript printers from linuxprinting.org's.

    Version numbers should be added tot the "upstream reference" if older binary printer drivers of a project can coexist with newer versions.
  5. An optional further classification of PPDs is possible under "upstream_reference", this classification should only be one level (no subdirectories). Packages that include PPDs from different manufacturers could use this to seperate the PPDs by make/manufacturer, packages that provide PPDs in several languages could seperate them by language code, ...
  6. PPDs may be gzipped to reduce disk space usage. CUPS, gnome-cups-manager and foomatic-gui can handle gzipped PPDs. Some projects include printer queue setup tools that can only work with PPDs that are NOT gzipped, e.g. hp-setup from HPLIP. Also note that gzipping the individual PPD files may increase the package size a lot. The decision is up to the package maintainer.
  7. Inside the PPDs a *Manufacturer string should be used as specified in the [http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf Adobe PPD specification v4.3]. To summarize: the same *Manufacturer string must be used by a manufacturer in each of their PPD files. Also, the string must be unique among manufacturers; two or more manufacturers may not use the same string. ?BR Appendix D of the PPD specification provides a list of *Manufacturer strings that should be used! Not all known manufacturers are in this list. For manufacturers not listed in the PPD specification we agree to use the *Manufacturer string as found in PPDs on www.linuxprinting.org.?BR The use of a unique *Manufacturer string allows printer queue setup tools to group printers of the same manufacturer together. The use of different *Manufacturer strings for the same manufacturer would cause a lot of confusion for users, if they look under the wrong Manufacturer name they may think their printers are not supported.

  8. Packages that need PPDs are responsible for symlinking to or directly looking for PPDs in /usr/share/ppd/<printer_driver_type>/. For example the cupsys package should simply look for all PPDs under /usr/share/ppd/.

  1. Packages that provide PPDs should NOT contain symlinks for other packages that need PPDs. The reason for this is that symlinks from different packages that provide PPDs can overlap each other resulting in duplicate drivers being seen by printer queue setup tools.
  2. User-provided or custom PPDs should be put into /etc/ppd/. Printer queue setup tools should be altered to look for user-provided or custom PPDs under this directory. User can drop their own PPDs or copy existing PPDs to this directory and modify them as needed before setup up their printer. Printer queue setup tools should also copy PPDs to this directory when a function like "Provide a PPD file..." is used. Therefore the /etc/ppd/ directory needs to be group-writable by user lpadmin, so that printer admins can install PPDs through e.g. gnome-cups-manager. Each package that provides a printer spooler (cupsys, lpr and lprng) should check if the /etc/ppd/ directory exists, if not create it and apply the necessary permissions.

Current issues