Any comments or suggestions to this Specification are welcome!!!
Please openly discuss this on debian-printing mailing list.
PPD File Structure Specification
Created: 05/01/2006 by ?PascalDeVuyst
Last update: 12/08/2006
Contributors: RogerLeigh, ?Hmh, ChrisLawrence and ?MartinPitt
When writing this specification the ?PrintingFilesystem Specification has been taken into consideration.
See also: SystemPrinting
There are several packages in Debian that provide prebuilt Postscript Printer Descriptions (?PPDs) 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 the CUPS "Add Printer" web interface, gnome-cups-manager, KDE Print 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:
- PPDs included in cupsys
- PPDs generated when installing package cupsys-driver-gutenprint
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:
- The database of PPDs should be located in a common directory.
- The PPDs should be seperated by printer driver type. This allows printer queue setup tools to include only the drivers they are interested in.
- 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.
- An optional further classification of PPDs is possible under "upstream_reference".
- The naming of PPD files is not important for this specification. This can be chosen freely by the debian maintainer.
A user configuring his printer should be able to find a printer model and driver for it easily. A printer model should be found under a unique manufacturer name and several drivers should be found under a unique model name. Therefore we should agree on a standard for the string values for the two most important keywords inside PPDs related to this: *Manufacturer and *NickName.
- 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.
- Two seperate packages should not provide the same PPDs to avoid duplicate printer model entries in printer queue setup tools.
- We need a directory /etc/ppd/ for user-provided and custom PPDs, printer queue setup tools should look for PPDs in this directory. Users can drop their own PPDs or copy existing PPDs to this directory and modify them as needed before they set up their printers with their favorite queue setup tool that automatically finds their PPDs.
- PPDs should be located in /usr/share according to the Filesystem Hierarchy Standard because they contain static and arch-independent information.
As common directory /usr/share/ppd/ should be used.
- 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.
- 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. I believe more and more printer manufacturers will provide CUPS rasterto drivers with prebuilt PPD files included.
- 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.
- Under /usr/share/ppd/cups-raster/:
- 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, ...
- PPDs may be gzipped to reduce disk space usage. CUPS, gnome-cups-manager, KDE Print 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.
Inside the PPDs a *Manufacturer string should be used as specified in the 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.
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 used by the Foomatic project at www.linuxprinting.org for compatibility with foomatic-db. Generic printer drivers should have a manufacturer indication of "Generic".
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.
Inside the PPDs a *NickName string of the following form should be used:
foomatic_make foomatic_model | requirements [(recommended)]
foomatic_make: the make/manufacturer of the printer according to the Adobe PPD Specification or as used by the Foomatic project at www.linuxprinting.org.
foomatic_model: the unique printer model name as used by Foomatic project at www.linuxprinting.org
Foomatic + driver_and_optional_version for foomatic-rip PPDs, indicates that foomatic-rip and driver_name should be installed for this PPD to work. Foomatic-rip PPDs can be recognized by the following string: *cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip". Don't include a Ghostscript indication or version in the driver_name for Ghostscript builtin drivers, only use the name of the driver as indicated by running the command "gs -h".
CUPS + driver_name_and_optional_version for cups-raster PPDs, indicates that CUPS and driver_name should be installed for this PPD to work. Cups-raster PPDs can be recognized by the following string: *cupsFilter: "application/vnd.cups-raster 100 rastertoxxx".
PostScript for PPDs for real PostScript printers.
foomatic_model and requirement should be seperated by a pipe character. This special character allows printer queue setup tools to easily seperate the printer model from the driver. Dashes or slashes are no good seperators for model and driver because a model name can have a dash or slash in its name.
A driver_name can have an optional version indication to inform the user that the PPD is only garanteed to work to its full extent with the specific binary printer driver version.
For the Foomatic recommended driver of a printer model a " (recommended)" indication should be added at the end of the NickName string. This makes choosing a driver for a printer model easier for users. Examples:
*NickName: "HP LaserJet 5 | PostScript (recommended)"
*NickName: "HP DeskJet 520 | Foomatic + pcl3"
*NickName: "HP DeskJet 3820 | Foomatic + hpijs 2.1.7 (recommended)"
*NickName: "HP DeskJet 400 | CUPS + Gutenprint v5.0.0"
Use of this defined NickName string for each PPD in Debian allows GUI printer queue setup tools like foomatic-gui to extract manufacturer, model and driver information from the NickName of e.g. static cups-raster PPDs and use this together with information from dynamically generated PPD files from e.g. foomatic-db. This information can be used to present the user a complete list of printer models he can add and allows to group together different drivers for the same printer model.
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/ and foomatic-gui should look for PPDs under /usr/share/ppd/foomatic-rip/ and /usr/share/ppd/postscript/ in addition to the PPDs that are generated from foomatic-db.
- 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.
- User-provided and custom PPDs should be put into /etc/ppd/. Printer queue setup tools should be altered to look for user-provided and custom PPDs under this directory and 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. Each package that provides a printer spooler (cupsys, lpr and lprng) should check if the /etc/ppd/ directory exists when installed, if not create it and apply the necessary permissions.