Differences between revisions 50 and 51
Revision 50 as of 2006-08-07 17:30:33
Size: 9558
Editor: ?PascalDeVuyst
Comment:
Revision 51 as of 2006-08-07 17:55:03
Size: 9931
Editor: ?PascalDeVuyst
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
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. 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 (GNOME), KDE Print Manager and foomatic-gui to provide users a printer model list so they can easily add their printers.
Line 38: Line 38:
 1. We need a directory /etc/ppd/ for user-provided and custom PPDs, printer queue setup tools should look for PPDs in this directory. User can drop their own PPDs or copy existing PPDs to this directory and modify them as needed before they set up their printer with their favorite queue setup tool that automatically finds their PPDs.  1. 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.
Line 76: Line 76:
 1. 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 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.
Line 88: Line 88:
 * MartinPitt: where to put user-provided PPD files? (Proposal: `/usr/share/ppd/custom -> /etc/ppd/` symlink; which package owns that?) It needs to be group-writable by user lpadmin, so that printer admins can install PPDs through e.g. gnome-cups-manager.  * MartinPitt: where to put user-provided PPD files? (Proposal: `/usr/share/ppd/custom -> /etc/ppd/` symlink; which package owns that?) It needs to be group-writable by user lpadmin, so that printer admins can install PPDs through e.g. gnome-cups-manager. '''Has been addressed in the specification. Printer queue setup tools should directly look under /etc/ppd for user-provided and custom PPDs, there is no need for a symlink.'''

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 the CUPS "Add Printer" web interface, gnome-cups-manager (GNOME), 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:

  • foomatic-filters-ppds
  • hpijs-ppds
  • PPD included in cupsys
  • PPDs generated when installing package cupsys-driver-gutenprint
  • linuxprinting.org-ppds
  • hp-ppd
  • gnustep-ppd

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

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. A fact is that 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.

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

  9. 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.
  10. 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.

Current issues

  • hplip-ppds package (now hpijs-ppds) incorrectly uses *Manufacturer: "HP (HPLIP)" inside PPDs. See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347264 bug #347264] [SOLVED].

  • foomatic-filters-ppds package contains the same hpijs ppds as hplip-ppds package. To avoid this duplication hpijs PPDs should be provided by only one package. The hpijs ppds should be provided by hplip-ppds package so they always match with the installed version of binary HPIJS Ghostscript drivers. Hpijs ppds from hplip project should be removed from package foomatic-filters-ppds, see [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347668 bug #347668] [SOLVED].

  • A package linuxprinting.org-postscript-ppds could be created to replace hp-ppd, this package should contain real PPDs for PostScript printers from foomatic-db project found at http://www.linuxprinting.org (this project currently contains real PPDs from different printer manufacturers). A new package linuxprinting.org-ppds has been created by ChrisLawrence [SOLVED].

  • CUPS does not yet include the symbolic link, see [http://bugs.debian.org/358186 bug #358186]. CUPS now directly looks for PPDs under /usr/share/ppd/ [SOLVED].

  • ?MartinPitt: where to put user-provided PPD files? (Proposal: /usr/share/ppd/custom -> /etc/ppd/ symlink; which package owns that?) It needs to be group-writable by user lpadmin, so that printer admins can install PPDs through e.g. gnome-cups-manager. Has been addressed in the specification. Printer queue setup tools should directly look under /etc/ppd for user-provided and custom PPDs, there is no need for a symlink.