{"id":19218907,"url":"https://github.com/openprinting/foomatic-db-engine-4","last_synced_at":"2026-06-19T13:31:18.158Z","repository":{"id":146907818,"uuid":"175984876","full_name":"OpenPrinting/foomatic-db-engine-4","owner":"OpenPrinting","description":"OpenPrinting printer support database - database engine, 4.0.x series","archived":false,"fork":false,"pushed_at":"2020-01-31T09:59:18.000Z","size":20586,"stargazers_count":2,"open_issues_count":0,"forks_count":2,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-01-04T19:25:02.618Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Perl","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/OpenPrinting.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-03-16T14:49:13.000Z","updated_at":"2022-11-27T23:54:33.000Z","dependencies_parsed_at":null,"dependency_job_id":"5bbc51f9-3ce9-4a13-88da-ddb9bd9fbc9c","html_url":"https://github.com/OpenPrinting/foomatic-db-engine-4","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenPrinting%2Ffoomatic-db-engine-4","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenPrinting%2Ffoomatic-db-engine-4/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenPrinting%2Ffoomatic-db-engine-4/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/OpenPrinting%2Ffoomatic-db-engine-4/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/OpenPrinting","download_url":"https://codeload.github.com/OpenPrinting/foomatic-db-engine-4/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":240292395,"owners_count":19778311,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-09T14:28:41.965Z","updated_at":"2026-06-19T13:31:18.112Z","avatar_url":"https://github.com/OpenPrinting.png","language":"Perl","funding_links":[],"categories":[],"sub_categories":[],"readme":"\nFoomatic 4.0.13\n===============\n\n\nfoomatic-db-engine\n------------------\n\nFoomatic's database engine generates PPD files from the data in\nFoomatic's XML database. It also contains scripts to directly generate\nprint queues and handle jobs.\n\n\nTill Kamppeter \u003ctill.kamppeter@gmail.com\u003e\nLars Uebernickel \u003clarsuebernickel@gmx.de\u003e\n\nhttp://www.openprinting.org/\n\nThis README contains mainly info for developers. See the file USAGE if\nyou want to know how to use Foomatic.\n\n\nCopying\n-------\n\nThis package and also the other Foomatic packages needed to run this\nare under the GPL. See http://www.gnu.org/.\n\n\nBugs\n----\n\nIf you spot a data error or any other bug, please report it on the\nOpenPrinting bug tracking system:\n\nhttp://bugs.linux-foundation.org/\n\nChoose \"OpenPrinting\" as the product and \"foomatic-db-engine\" as the\ncomponent.\n\n\nIntro\n-----\n\nThis is the stable version of Foomatic. This version is also the base\nof our database web interface on\n\nhttp://www.openprinting.org/\n\n\nNew features for Foomatic 4.0.x\n-------------------------------\n\nAdded in 4.0.0:\n\n - Support for the PDF-based printing workflow. foomatic-rip now\n   understands both PostScript and PDF as input. PPDs are generated\n   with two \"*cupsFilter\" lines now, so that CUPS knows that also PDF\n   can get fed in. By the cost factors PDF is made the preferred input\n   format.\n\n - foomatic-rip is rewritten in C, so that libraries can be used\n   without needing Perl bindings.\n\n - Support for CUPS custom options. If a printer/driver combo has\n   numerical, string, or password options, appropriate keywords are\n   added to the PPD so that these options are also recognized as CUPS\n   custom options (see\n   http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html for the\n   CUPS PPD extension for custom options).\n\n - PJL/JCL options in PPD files are now generated in the standard way\n   as defined by the PPD specs. Foomatic keywords are only used if\n   really necessary.\n\n - Generated PPDs have now an additional \"*cupsFilter:\" line to tell\n   CUPS that foomatic-rip understands PDF input (output of the\n   \"pdftopdf\" CUPS filter).\n\n - Driver XML files can now have a new \"\u003cprototype_pdf\u003e\" tag in the\n   \"\u003cexecution\u003e\" section, to supply a different command line prototype\n   for PDF input. If left out, the same command line prototype is used\n   for both PDF and PostScript input.\n\n - Margins in generated PPDs now default to safer values and not to\n   zero if no margins are specified in the XML files.\n\n - CUPS page accounting can be suppressed on a per-driver basis now,\n   via the tag \"\u003cnopageaccounting\u003e\" and the PPD keyword\n   \"*FoomaticRIPNoPageAccounting: True\".\n\n - Added new \"foomatic-ppd-to-xml\" utility to generate Foomatic XML\n   files corresponding to a given PPD file.\n\n - Printer/driver relations now can be defined by the \"\u003cprinters\u003e\"\n   section in the driver XML file or by the \"\u003cdrivers\u003e\" section in the\n   printer XML file. Before, only the former was possible.\n\n - Added find_printer() method, to search for printers in the\n   database. This method is especially used by the web query API for\n   automatic driver/PPD downloads from the OpenPrinting web site. It\n   can also be used in a local installation with the new\n   \"foomatic-searchprinter\" utility.\n\n - Added support for more detailed driver information, like license,\n   whether it is free, whether it comes from the printer's\n   manufacturer, support contacts, short description, by-task\n   ratings. This gives more information to decide on downloading and\n   installing a driver for both driver auto download and browsing the\n   OpenPrinting web site. The information can also be used by printer\n   setup tools using a locally installed Foomatic database. The\n   information is available in the driver XML files (there one enters\n   it), the PPD files, and also in the device ID strings, defined in\n   the PPDs (so that the information goes into the output of \"lpinfo\n   -l -m\" of CUPS).\n\n\nNew features for Foomatic 3.0.x\n-------------------------------\n\nAdded after 3.0.2:\n\n - Support for on-the-fly PPD generation by CUPS 1.2. Now all Foomatic\n   PPDs appear in the model lists of the CUPS web interface without\n   needing to pre-compile the PPDs. The PPDs get actually generated if\n   one selects them for the new print queue to be set up.\n\nAdded in 3.0.2:\n\n - Some fixes to make foomatic-rip more robust against weird input via\n   the command line or environment variables are done. This solves the\n   problem of an attacker being able to run arbitrary commands as \"lp\"\n   (or however the spooler's special user is named) on the print\n   server (Security Advisory CAN-2004-0801).\n\n - Workaround for PostScript generation bug in all OpenOffice.org\n   1.1.x versions.\n\n - Let the PPD generator use the manufacturer as defined in the\n   Foomatic database and not the one from the IEEE-1284 auto-detection\n   ID string for the \"*Manufacturer: ...\" tag of the PPD files, as in\n   the IDs the manufacturer names often do not comply with the Adobe\n   specs (as \"Hewlett-Packard\", \"HP\" has to be used).\n\nAdded in 3.0.1:\n\n - CUPS raster drivers can now be used with any spooler. This makes a\n   lot of newer commercial or manufacturer-supplied printer drivers\n   available for non-CUPS environments. To use a CUPS raster driver\n   with a spooler other than CUPS, you need to install Ghostscript\n   (preferrably ESP Ghostscript) with CUPS raster support, the\n   appropriate CUPS raster driver. You do not need to install the\n   complete CUPS package, the CUPS libraries are enough (libcups and\n   libcupsimage, usually in the \"libcups\" package of your\n   distribution) and to compile CUPS raster drivers you need also the\n   header files of the CUPS library (libcups-devel, cupsys-dev, or\n   similar package of your distro). Then you can set up a print queue\n   with the PPD file of the CUPS driver the same way as if you had a\n   native PostScript printer.\n\n - If a printer/driver combo has Foomatic-defined JCL options and the\n   driver already generates a JCL header, the JCL options are merged\n   into the header produced by the driver.\n\n - Workaround for newly introduced PostScript generation bug of\n   OpenOffice.org 1.1.0 (OOo puts settings for whole document into\n   \"%%PageSetup\" section of first page).\n\n - Added \"use strict;\" to the most important Perl scripts, clean-up of\n   the scripts (Thanks to Patrick Powell from LPRng)\n\n - Improved LPRng support (Thanks to Patrick Powell from LPRng)\n\n - Printer listing options and auto-selection of recommended driver\n   for the PPD generator foomatic-ppdfile (Thanks to Patrick Powell\n   from LPRng).\n\n - Support for string options and additional operation modes for\n   foomatic-addpjloptions (Thanks to Patrick Powell from LPRng).\n\n - Additional checks in the configure scripts (Thanks to Patrick\n   Powell from LPRng).\n\n - Composite options can be nested now (normal and forced composite\n   options can be mixed).\n\n - Several modifications to make the PPD files compatible with the\n   PostScript drivers for Windows: 100 instead of 999 choices for the\n   \"Copies\" options, no \",\" and \"+\" in the \"*NickName\" and\n   \"*ShortNickName\" entries, optional cutting of the long names of the\n   options and choices (translation strings in the PPDs) to 39\n   characters for compatibility with the Microsoft PostScript driver\n   and the original PostScript driver for Windows of CUPS. All this is\n   not required by the Adobe specification for PPD files.\n\n - Compatibility fixes for IRIX and the *BSD operating systems.\n\n - Script to update the \"gutenprint\" driver entry in the database\n   using the src/foomatic/foomatic-printermap file of the source\n   tarball of Gutenprint 5.0.x.\n\n - perltoxml() Perl function in DB.pm to generate XML database entries\n   from PPD files (thanks to Tim Waugh from Red Hat).\n\n - Let foomatic-ppdfile (which can be also called under the name\n   \"foomatic-datafile\", for compatibility with frontends) accept and\n   ignore the \"-t\" option for backwards compatibility. Now the KDE\n   Printing Manager works correctly again.\n\n - Fixed PPD file generation so that the files pass the \"cupstestppd\"\n   of CUPS 1.1.20.\n\nAdded in 3.0.0:\n\n - For all supported spoolers (CUPS, LPRng, LPD, GNUlpr, PPR, PDQ,\n   CPS, no spooler) the same PostScript-to-printer's-native-language\n   filter (RIP, Raster Image Processor), foomatic-rip is\n   used. foomatic-rip detects automatically from which spooler it is\n   called.\n\n - foomatic-rip gets the info about the printer's capabilities and the\n   driver options and default settings always from PPD files,\n   independent which spooler is used. It is possible to use\n   Foomatic-generated PPD files (usually for non-PostScript printers)\n   or manufacturer- supplied PPD files of PostScript printers. So\n\n    o PPD files of PostScript printers can be used with every spooler,\n      not only with CUPS and PPR and on all spoolers all options will\n      be available. So PostScript printers work always \"Perfectly\".\n\n    o With the PPD file one has one configuration file for every place\n      where information about the printer and its options is needed:\n      The print queue itself, PPD-aware applications (as Star Office,\n      OpenOffice.org, GIMP, ...), and clients (Windows, Mac, Unix with\n      arbitrary spooler). The PPD format is a standard format used by\n      every modern operating system.\n\n - PPD building and PostScript processing is done according to the\n   Adobe specifications DSC (Document Structuring Conventions) and PPD\n   (PostScript Printer Description) as published on\n\n   http://partners.adobe.com/public/developer/ps/index_specs.html\n\n - foomatic-rip inserts all default settings from the PPD file (so you\n   can edit the \"*Default...\" lines in the PPD files to set the\n   defaults), reads option settings from the user's command line, and\n   from the PostScript data stream. Settings in the PostScript data\n   stream have the highest priority to assure that what one sets in an\n   application is used. Depending on the option type the settings are\n   applied to the renderer's (usually Ghostscript's) command line, to\n   the JCL header, or stuffed in at the right place of the PostScript\n   data stream.\n\n - Support for option settings only acting on a certain page selection\n   (example: First page on letterhead paper from tray 1, rest on plain\n   paper from tray 2). Settings must be put into the\n   \"%%BeginPageSetup\"/ \"%%EndPageSetup\" sections (or at least right\n   after the \"%%Page:\" comments) of the appropriate pages in the\n   PostScript input file. They can also be specified on the command\n   line by specifying a page range before the option name (ex: \"lpr -o\n   1,5-8:ColorMode=CMYK file.ps\"). If necessary, the renderer (usually\n   Ghostscript) is stopped and restarted in the middle of the job,\n   when certain pages need a different command line for the\n   renderer. The bug of Star Office/OpenOffice.org inserting the\n   \"%%BeginSetup...%%EndSetup\" section after the first \"%%Page:\"\n   comment is taken care of.\n\n - foomatic-rip does neither use temporary files on the disk, nor does\n   it need to load huge documents completely into memory. All is done\n   in data streams where not more data than necessary is buffered. To\n   make this possible foomatic-rip forks into up to six sub-processes.\n\n - The installation is very easy, one needs only foomatic-rip\n   (absolutely monolithic, no Perl modules needed), a PPD file, and\n   optionally foomatic-gswrapper. No different files for different\n   spoolers.\n\n - Custom page size support with all spoolers when the PPD file has\n   Adobe-compliant definitions for usage of custom page sizes.\n\n - The spooler-less printing mode of foomatic-rip can be used for\n   testing and debugging PPD files in arbitrary directories, one\n   simply specifies them with the new \"--ppd\" option.\n\n - With PDQ one can print arbitrary file types now, and even set up\n   raw printers. The PDQ driver files are generated by foomatic-rip,\n   so the user does not need to download more files than with other\n   spoolers.\n\n - Under PPR 1.50 and newer foomatic-rip runs as a PPR RIP, under\n   older versions, as before, as a PPR interface.\n\n - foomatic-configure sets up printer queues based on Foomatic\n   database entries, arbitrary third-party PPDs (as shipped with\n   PostScript printers), or raw queues.\n\n - foomatic-configure is much faster when copying or modifying print\n   queues now, as it does not rebuild the PPD from the Foomatic\n   database all the time (as long as one does not force a rebuild with\n   \"-f\").\n\n - foomatic-addpjloptions works also in regular installations now, not\n   only in \"inplace\" installations.\n\n - foomatic-compiledb generates only PPD and XML files now.\n\n - foomatic-datafile is renamed to foomatic-ppdfile, a compatibility\n   link named foomatic-datafile is set. foomatic-ppdfile generates\n   only PPDs, the options \"-t\" and \"-f\" are ignored.\n\n - foomatic-configure, foomatic-printjob, and all the other scripts\n   have the same command lines as in Foomatic 2.0. Exceptions: In\n   foomatic-configure \"--oldppd\" was dropped, \"--ppd\" (for setting up\n   a queue with a third-party PPD file) added, and the meaning of \"-f\"\n   (force rebuild of PPD) changed.\n\n - Option groups: Options can be put into groups and subgroups in the\n   PPD files, so that GUIs can present them in a structured way (in\n   tabs or in a tree structure). It is nearly completely functional,\n   the only thing missing is translation support (\"long names\" for the\n   groups, as \"Adjustments and Corrections\" for \"Adjustment\", or\n   translations to other languages). Now the PPD generator makes\n   trivial translations (\"ThisIsAGroup\" -\u003e \"This Is A Group\")\n   automatically.\n\n - Composite options: This is a new option type to make it easier for\n   users to choose the best settings for a certain printing task,\n   especially if the driver has very many options. The idea is to have\n   an enumerated choice option which does not directly modify\n   something in the driver's command line but sets several of the\n   other options.\n\n   We will have a \"Printout Mode\" option for all printers with the\n   following choices:\n\n      Draft\n      Normal\n      High Quality\n      Very High Quality\n      Photo\n\n   For an Epson Stylus Color 680 with Gutenprint it sets the options\n   resolution, dithering, and image type as follows:\n\n      Choice           Resolution     Dither            ImageType\n      ------------------------------------------------------------------\n      Draft            180x180 dpi    Very Fast         LineArt\n      Normal           360x360 dpi    Adaptive Hybrid   Photographs\n      High Quality     720x720 dpi    Adaptive Hybrid   Photographs\n      Very High Qual.  1440x720 dpi   Adaptive Hybrid   Photographs\n      Photo            2880x720 dpi   Even Tone         Photographs\n\n   The mentioned settings set all the color mode to \"Color\", there are\n   also choices with a \".Gray\" modifier (ex: \"Normal.Gray\" which set\n   the color mode to \"Grayscale\", but the other mentioned options as\n   the standard variants (\"Normal\").\n\n   The member options of the composite option all get one choice\n   called \"FromPrintoutMode\"/\"Controlled by 'Printout Mode'\" added,\n   which gets their default setting. If this choice is selected, the\n   option is set by the composite option according to the table. If\n   the user wants to modify one of the individual member options, he\n   simply chooses a value other than \"FromPrintoutMode\" for this\n   particular option. In addition the member options will be put into\n   a group (named \"Printout Mode\"). and the composite option goes into\n   the same group as \"PageSize\", \"InputSlot\", ... So the user sees the\n   composite option on the \"Front page\" of the GUI and can quickly set\n   up print jobs without getting confused. The user with more special\n   demands goes to the tab with the member options and makes detailed\n   choices.\n\n - Forced composite options: These are special composite options where\n   the user cannot set the individual member options, but only the\n   composite option (the user is forced to use the composite\n   option). This allows options acting at two or more places, for\n   example a \"PageSize\" option for a driver which is a filter\n   translating Ghostscript bitmap output to the printer's\n   language. One lets one member option be an option inserting\n   PostScript code for the page size into the PostScript input data\n   stream for Ghostscript, and another member option insert the\n   correct bitmap size into the filter's command line. The user sees\n   only the composite option and sets the paper size with it as usual.\n\n - String and password options: These options allow the user to supply\n   nearly arbitrary strings (a length limit and restrictions be a list\n   of allowed characters or a Perl regular expression can be set) to\n   the printer driver, for example names of color calibration files,\n   fax numbers, passwords for confidential jobs, ... Frequently needed\n   strings can be added as enumerated choices, so a frontend can show\n   the option as a combo-box. The enumerated choices are also used for\n   frontends which only support options as defined by the PPD spec.\n\n - New handling of numerical options in the PPD files:\n   \"*Default\u003coption\u003e: ...\" now always contains one of the enumerated\n   choices to be Adobe-compliant, the exact default value for\n   Foomatic-aware applications is stored with the new\n   \"*FoomaticRIPDefault\u003coption\u003e: ...\" keywords now.\n\n - URIs (Unified Resource Identifiers, the descriptions for the\n   printer connection type used with the \"-c\" option of\n   foomatic-configure) are exactly the same as under CUPS now. The\n   only difference was that before for local printers always URIs\n   beginning with \"file:\" were used, now \"parallel:\", \"usb:\", or\n   \"serial:\" is used. The old form with \"file:\" is still accepted for\n   compatibility.\n\n - For USB printers CUPS 1.1.17 and newer supports URIs which refer to\n   manufacturer, model, and serial number and not to the device file\n   (/dev/usb/lp*) any more. This way the queues still work when the\n   printers are plugged in or turned on in another order in a later\n   session (the printers can get different device files\n   then). Foomatic now automatically converts the conventional USB\n   URIs to the new ones when an appropriate versions of CUPS is used.\n   When copying a queue to another spooler the URI is converted back\n   in the copied queue.\n\n - Support for the MTink daemon from the MTink package\n   (http://xwtools.automatix.de/). MTink allows monitoring the ink\n   levels of Epson inkjets also while printing.\n\n - Non-printable margins: Both printer and driver XML database entries\n   should get a new section for unprintable margins, so that the\n   \"*ImageableArea\" entries in the PPD files can be correctly set.\n   Entries should be possible for printers (printer XML file), for\n   drivers (main part of driver XML file), for printer/driver combos\n   (in printer list of driver XML file), and they can contain general\n   margins (valid for all paper sizes) and paper-size-specific\n   margins.  If for one \"*ImageableArea\" entry in a PPD file more than\n   one of the above mentioned possible margin entries applies, the\n   \"worst case\" (individually determined for each page border) is\n   inserted. If the unprintable margins of a printer depend on options\n   settings, the \"worst case\" is chosen, too.\n\n - Facility to make a package consisting of all possible Foomatic PPD\n   files, foomatic-rip, and foomatic-configure, see\n   README.build-foomatic-filters-ppds for how to proceed.\n\n - Support for inserting arbitrary constant entries (as a default\n   resolution if there is no \"Resolution\" option) into the PPD\n   file. The entries can be printer-specific, driver-specific, or\n   printer/driver-combo-specific.\n\n - Extended structure for auto-detection info in printer XML files:\n   General section for entries valid for both USB and parallel port\n   connection, possibility to insert the constant part of the original\n   IEEE-1284 ID string. The ID string will also be inserted into the\n   PPD file.\n\n - Added a facility to chnage all the cryptic numerical printer IDs\n   from the old PostGreSQL time to clear-text printer IDs. With a\n   translation function it is assured that one can still use the old\n   IDs, for example to not break links to the old linuxprinting.org\n   web site.\n\n - The Foomatic database uses clear-text printer IDs for all printers\n   now.\n\nIdeas for future releases:\n\n - (Soon) Add support for all PPD extensions for the Commom Printing\n   Dialog:\n   http://www.linuxfoundation.org/en/OpenPrinting/CommonPrintingDialog,\n   http://www.linuxfoundation.org/en/OpenPrinting/PPDExtensions\n\n - Option conflicts: PPDs allow to define conflicts between option\n   settings, so that one cannot set up things which the printer cannot\n   do or which dont make sense (Duplex on transparencies, printing\n   from tray 4 when only 2 trays are installed, ...).\n\n - Printer and driver classes: The class XML files should look like\n   printer or driver entries, with the same fields and with an\n   additional member list. If one marks an option or an option choice\n   as being valid for a class, it is valid for all member printers and\n   classes, If a printer or driver is a member of a class, all fields\n   which are left blank in this entry, are filled in with the value\n   defined in the appropriate field of the class. If the class\n   contains a comment text, it is shown in addition to the printer's\n   or driver's own text. This saves from a lot of duplicate entering\n   of data when adding printers, drivers, options, choice, option\n   groups, or option conflicts to the database.\n\n\nGeneral features\n----------------\n\n - The XML database is fully internationalizable, For all\n   human-readable strings translations into different languages can be\n   added and the web query API allows localized requests with answers\n   in the requested language. The OpenPrinting web site appears only\n   in English currently. Not only translations can be done but there\n   can be also different entries for the same printer driver for\n   different regions, so that localized driver packages can get\n   offered for automatic download.\n\n - There is code to manipulate the XML files of the database. You can\n   load them and get Perl data structures out of them. You can\n   generate a printer overview list which shows all printers and for\n   each printer which drivers make this model work and you can also\n   generate an XML file with all information needed to use a certain\n   printer with a certain driver, which is the basis for the PPD files\n   which are used to configure printer queues under a spooler. These\n   XML files can also be transformed into a Perl data structure.\n\n - All XML handling is done by two C programs, one makes use of libxml\n   to do a DOM parsing of all types of XML files appearing in the\n   Foomatic system to get Perl data structures out of them, because\n   Foomatic does all printer configuration, job manipulation,\n   printing, and filtering with Perl scripts. The other one does\n   XML-to-XML operations: the generation of the printer overview list,\n   and the generation of the printer/driver combo files. These\n   operations involve reading hundreds of files, cutting them apart\n   and assembling them together in another way. To make this as fast\n   as possible and also less memory-consuming, we do not use libxml,\n   but did the parsing \"manually\" to keep data moving operations low.\n\n - All configuration work, especially the generation of the PPD files\n   is done by Perl code, because it is much easier to implemnent text\n   manipulation operations in Perl.\n\n - A program foomatic-configure is provided which implements complete\n   printer configuration for the common spoolers. It is designed to\n   support CUPS, PPR, PDQ, LPRng, LPD, GNUlpr, and direct spooler-less\n   printing and it is designed to make it easy to write GUI or\n   automagic printer configuration tools. It also transfers queues\n   between different spoolers and generates Perl data structures or\n   XML files so that frontends can build menues.\n\n - The program foomatic-searchprinter finds printers in the local\n   database, based on manufacturer/model search terms or the printer's\n   device ID. This allows to make scripts which find the printer ID\n   and suitable drivers automatically.\n\n - Printing and managing print jobs is done by foomatic-printjob, you\n   supply exactly the same command line options for doing the same\n   tasks on every supported spooler.\n\n - PJL (Printing Job Language) options can be read from the printer\n   and added into the local Foomatic database. This allows access to\n   many functions of the printer which are not supported by the\n   driver, as paper tray selection, toner saving, toner density,\n   ... This is done with foomatic-getpjloptions and\n   foomatic-addpjloptions. Usually, PJL is only supported by PCL or\n   PostScript laser printers.\n\n - The PPD files serve also for PPD-aware applications as Open Office,\n   the GIMP (Gutenprint plug-in and printers not directly supported by\n   Gutenprint), GPR, Windows/Mac clients using their PostScript driver\n   (and the Linux/Unix server using the Linux driver for the\n   printer). They give access to all the driver's options in the\n   printing dialogs of said applications. This works for all spoolers.\n\n\nThe upshot of all this is that you can now make changes easily and run\nthe scripts to calculate out whatever your printer/spooler needs\ndirectly.\n\n\nPrograms and important files from this package\n----------------------------------------------\n\nNote: The scripts appear as \".in\" files in the source tree and BZR\nrepository, because the path for the Perl interpreter/the bourne shell\nis inserted by the \"configure\" script.\n\nconfigure.ac\n\n  The source from which GNU autoconf generates the \"configure\" script\n\nacinclude.m4\n\n  Additional macros for the \"configure\" script\n\nmake_configure\n\n  Calls aclocal and autoconf to generate \"configure\" from \"configure.ac\" \n  and \"acinclude.m4\"\n\nMakefile.in\n\n  The template from which \"configure\" generates the Makefile\n\ninstall-sh\n\n  Helper script for \"configure\"\n\nfoomatic-ppdfile\n\n  This program will compute the spooler-independent Foomatic PPD file\n  for any valid printer/driver combo available in the Foomatic\n  database, both for printing with foomatic-rip and for\n  applications/clients being able to access the printer's\n  options. This script serves also as on-the-fly PPD generator for\n  CUPS 1.2.x and newer. \"make install\" creates a symlink named\n  /usr/lib/cups/driver/foomatic to this script and so CUPS makes all\n  PPDs of the local database available without the PPDs needing to\n  exist physically. CUPS automatically calls foomatic-ppdfile if one\n  of the PPDs is requested. This way in most printer setup tools (all\n  which fully support CUPS 1.2.x and newer) all Foomatic PPDs are\n  available, without explicit Foomatic support by the printer setup\n  tool.\n\nfoomatic-configure\n\n  See USAGE for more info.\n\n  This is the great-grandady of printer configuration programs.\n\n  You can invoke this to configure a printer under any spooler with any\n  sort of printer connection.\n\n  The printer can be either one in the Foomatic database, it can be\n  one for which you have a PPD file (for example a PostScript printer\n  with the PPD from the Windows driver) or a printer which you want to\n  use without driver/filter (raw queue).\n\n  It also includes methods to summarize the current configurations, to add\n  new queues, reconfigure existing queues, enumerate the printers known to \n  the world, and return xml data objects describing individual printers and \n  drivers.\n\n  It should be very straightforward to write interactive printer\n  configuration tools around this script:\n\n  1. foomatic-configure -O prints the XML db overview on stdout\n  2. foomatic-configure -Q prints an XML summary of printer queues\n  3. foomatic-configure -X prints the XML for a database object\n  4. foomatic-configure with various options does the actual setup\n  5. foomatic-configure -P prints Perl structures for frontends\n  6. foomatic-configure -C copies queues, also to other spoolers\n  7. foomatic-configure -D sets a queue as the default queue\n  8. foomatic-configure -R removes a queue\n\t\n  foomatic-configure supports CUPS, PPR, PDQ, LPD, LPRng, GNUlpr, and\n  direct spooler-less printing nearly completely. The program is \n  structured with a dispatch table; for the cost of a few Perl \n  functions it can support even more spoolers. If not told, it attempts\n  to guess which spooler to use, or asks.\n\n  Regarding item (2), the summary of current config.  It shows each\n  queue, giving attributes for spooler, and various settings.  Queues\n  with the foomatic attribute set to zero are neither queues set up with\n  the help of the Foomatic database nor set up with a PPD file (and\n  foomatic-rip in case of LPRng, LPD, GNUlpr, PDQ, or no spooler). These\n  queues cannot be modified by foomatic-configure. Trying to modify them\n  would turn them into raw queues. The summary shows also which is the\n  default queue, if a default queue is defined for the current spooler.\n  The $PRINTER environment variable is not taken into account here.\n\n  For all spoolers, foomatic-configure fully groks the configuration\n  format. It rewrites the whole thing, preserving ordering, comments,\n  etc, and regularizing the syntax on each rewrite.  So it can change\n  entries that are clearly foomatic-rip/PPD ones, and leave others\n  alone. Also changes of the option default settings done manually (or\n  with GUI tools) are preserved when modifying a queue.\n\n  It is wrong to store configuration in a weird place just because foomatic \n  is used: the user should be able to edit the config by hand the\n  old-fashioned way...\n\n  When configuring printers, the PPD file is put into \n  /etc/foomatic/\u003cspooler\u003e/ (and if needed symlinked to from elsewhere).\n  The PPD files are Adobe-compliant and can also be symlinked/used by \n  applications or clients. They get a basename taken from the queue name.\n\n  For printer configuration frontends it is necessary to get all info\n  about the queue configuration, the options, possible settings, and\n  default settings. This info can be retrieved as a Perl data\n  structure. The structure produced by\n\n     foomatic-configure -q -P \u003e testfile.pl\n\n  can be read by the following Perl script example.pl\n\n     #!/usr/bin/perl\n     my @QUEUES;\n\n     eval (join('',(\u003cSTDIN\u003e)));\n\n     my $i;\n     my $N = $#QUEUES + 1;\n     print \"$N Queues\\n\";\n     for ($i = 0;  $i \u003c $N; $i++) {\n         my $n = $i + 1;\n         print \"$n : $QUEUES[$i]-\u003e{'queuedata'}{'queue'}\\n\";\n     }\n\n  with\n\n     cat testfile.pl | ./example.pl\n\n  Queue copying especially allows to switch between spoolers overtaking\n  ones queues with all settings and adjustments.\n\nfoomatic-searchprinter\n\n  With this tool it is easy to find the desired printer in the\n  database. You do not need to know the exact manufacturer and model\n  name and how it is written in the database. foomatic-searchprinter\n  matches what is closest to your search term. You can even use the\n  IEEE-1284 device ID read from your printer as search term. This\n  tool together with foomatic-configure allows to write printer setup\n  tools for fully automatic print queue setup. Results are shown\n  sorted by relevance and the threshold for accepting results and the\n  amount of results to be shown is adjustable. See\n  \"foomatic-searchprinter -h\" for available options.\n\nfoomatic-getpjloptions\n\n  Reads the PJL options from local (parallel, USB. serial, ...) or\n  remote (only socket, LPD is not bi-directional) printers to standard\n  output. They can be piped into foomatic-addpjloptions to add them to\n  the database. Call the program without arguments for help.\n\nfoomatic-addpjloptions\n\n  Add the PJL options listed by a printer to the Foomatic\n  database. The option list is read from a file or from standard\n  input. The ID of the printer for which the options are has to be\n  provided (option -p). You can add all PJL options or only the most\n  important ones (-i). When you are adding the options from a file,\n  you are asked whether the printer ID is correct, but you can turn\n  this off if you want (-f). Call the program with the -h option to\n  get help.\n\n  Note: The program needs the three files foomatic-templates/pjl*.xml\n\n  Example for making available the PJL options of the networked HP\n  LaserJet 4050 (Foomatic ID: HP-LaserJet_4050), hostname printer6,\n  port 9100:\n\n  # Remove the \"native\" PJL options from the database\n  rm -f `grep -li \"pjl\" db/source/opt/*.xml`\n  # Remove the options from a former PJL option poll on the same printer\n  rm -f foomatic-db/opt/pjl-HP-LaserJet_4050-*\n  # Get the PJL options from the printer\n  foomatic-getpjloptions printer6 9100 | foomatic-addpjloptions -p HP-LaserJet_4050\n  # Move the XML files into the database\n  foomatic-kitload -k foomatic-db/\n  # Set up printer queue\n  foomatic-configure -n LaserJet4050 -c socket://printer6:9100/ \\\n     -d pxlmono -p HP-LaserJet_4050\n\n  Instead of using \"foomatic-configure\" you can also generate the PPD\n  file:\n\n  ./foomatic-ppdfile -d pxlmono -p HP-LaserJet_4050 \u003e lj4050.ppd\n\n  and set up the queue manually as described on\n  http://www.openprinting.org/\n\n  For CUPS you can for example do:\n\n  lpadmin -p LaserJet4050 -E -v socket://printer6:9100/ -P lj4050.ppd\n\nfoomatic-kitload\n\n  This program installs a foomatic data kit into the local data\n  library.  It takes a -k \u003cdirname\u003e option, where \u003cdirname\u003e is the\n  toplevel directory of a foomatic driver \"kit\".  A \"kit\" is a\n  selection of XML source files arranged exactly as in the source/\n  section of the master database (ie, opt/ driver/ printer/ subdirs).\n  Gutenprint foomatic-generator produces exactly such a kit.\n\n  Foomatic-kitload is moderately paranoid about kits: the kit must\n  contain at least one of printer/ driver/ and opt/; the kit must\n  contain only files ending in .xml, the kit cannot be the local\n  library itself, etc.  But it does not inspect the contents of the\n  kit files in any way.\n\nfoomatic-printjob\n\n  See USAGE for more info.\n\n  This program implements all the logic for controlling the dynamic\n  elements of queues. In other words, jobs. It'll submit them, provide\n  status on them, cancel them, etc. This provides an easy way for\n  application authors to print in a spooler and driver neutral way.\n\nfoomatic-compiledb\n\n  This program will run around and generate combo data for all valid\n  printer/driver combinations (or for selected drivers). The data is put\n  into one directory and it is generated in a format specified by the user\n  (PPD files or printer/driver combo XML files).\n\n  compile_db takes a -j# flag: it will run that many compute processes\n  in parallel. You should run compile_db with a -j flag to specify how\n  many processes to run concurrently (Gratuitous feature: you can add\n  more processes in the middle without conflict! Just run another with\n  -f until they all finish).\n\n  Generally, compile_db should just not be necessary except for people\n  who want to distribute sets of configuration files. foomatic-ppdfile and\n  especially foomatic-configure will automagically compute just what they \n  need at runtime.\n\nfoomatic-combo-xml\n\n  The Foomatic accelaration engine written in C, it computes\n  printer/driver combo XML files or the printer overview XML file in\n  less then two seconds (on a crappy 128MB/350MHz\n  machine). foomatic-compiledb needs less than three minutes for its\n  job on a two-processor 1GB/1GHz machine. The printer/driver combo\n  XML files are computed around 600 times faster than with the pure\n  Perl programs of the beginning of the XML Foomatic. In addition,\n  foomatic-combo-xml does not need more than 10 MB of memory.\n\n  The program is called by the Foomatic Perl library, but can also be\n  called stand-alone, call the program without command line options to\n  know how to use it.\n\n  foomatic-combo-xml does not need any XML parsing libraries, to make\n  it faster and less memory-consuming, the XML files are somehow\n  \"manually\" parsed.\n\nfoomatic-perl-data\n\n  The XML-to-Perl translator, also written in C. This program reads\n  the XML files of the Foomatic database and translates them into Perl\n  data structures, so that the Perl scripts can access the data.\n\n  The intention of this program is to not need the many non-standard\n  Perl XML libraries which would make the installation of Foomatic\n  very awkward. Now only the libxml C library is needed, a library\n  which ships with most distributions of free operating systems. One\n  can use either libxml 1.x (1.8.17 and newer) or 2.x, but 2.x is\n  recommended.\n\n  Without any C helper programs the following problems appeared:\n\n  - The thing was *at least* an order of magnitude slower than life\n    under Postgres and Perl was. It took hours to run compile_db, and\n    up to some minutes (at least a few seconds) to compile one combo.\n    The first one took more time as the option cache loaded.\n\n  - Memory: compiledb compute processes peaked at about 150MB RAM.\n    You could turn down the number of computations per process, but it\n    never got much below 130MB.\n\n  - Due to the slowness of the Perl XML handling an on-disk cache was\n    used.  This lead to old files from the cache being used when one\n    changed something in the database and forgot to delete the cache.\n\n  - Many non-standard Perl libraries were needed which made the\n    installation of Foomatic rather difficult. Now only the libxml C\n    library is needed. This library ships with every modern distro of\n    GNU/Linux.\n\nfoomatic-fix-xml\n\n  Run this program if you have compiled foomatic-perl-data against\n  libxml 1.x and you have old database entries with a leading blank\n  line. libxml 1.x chokes on leading blank lines.\n\nfoomatic-cleanupdrivers\n\n  Removes all driver entries with empty driver command lines. This way\n  frontends do not show printer/driver combos which do not work.\n\nfoomatic-preferred-driver\n\n  Sets a recommended driver for every printer which has no recommended\n  driver entry or has one pointing to a driver which does not exist in\n  the local Foomatic database (for example when you have removed a\n  driver entry from the database which belongs to a driver which is\n  not built into your Ghostscript).\n\nfoomatic-nonumericalids\n\n  This script changes all old cryptic numerical printer IDs from the\n  old PostGreSQL time to clear-text printer IDs in the installed\n  Foomatic database. The current \"foomatic-db\" has no numerical IDs\n  any more (this script has been applied to it), but if you use and\n  older Foomatic database (for example to match the of your distro)\n  you can change the IDs with this script. With a translation table it\n  is assured that one can still use the old IDs.\n\nfoomatic-replaceoldprinterids\n\n  Replaces references to old numerical or otherwise obsolete printer\n  IDs in arbitrary files. By default it uses the db/oldprinterids file\n  of the current Foomatic database as translation table, but you can\n  use arbitrary translation tables. You can also give regular\n  expressions (Perl) for the text surrounding the IDs. Do\n  \"foomatic-replaceoldprinterids -h\" to know how to use it.\n\nfoomatic-ppd-to-xml\n\n  Generates a printer XML file from a given PPD file. This is for\n  example used to make database entries for printers for which there\n  is a manufacturer-supplied PPD file.\n\nfoomatic-printermap-to-gutenprint-xml\n\n  Updates the driver XML file for the Gutenprint driver to the state of\n  the foomatic-printermap file in the Gutenprint source tree. Used to\n  update the driver XML file for Gutenprint in the OpenPrinting database.\n\nfoomatic-ppd-options\n\n  Lists the options in a PPD file one the screen.\n\n\nFilters\n-------\n\nTo be able to print with the PPD files and queues made with the stuff\nin this package, you need only the foomatic-rip filter provided by the\n\"foomatic-filters\" package.\n\nfoomatic-rip\n\n  See the documentation of the \"foomatic-filters\" package for more info.\n\n  This is a universal print filter which works with all printer\n  spoolers auto-detecting the spooler from which it is called. Its job\n  is to translate the incoming data (PostScript or PDF in most cases)\n  to the printer's native language taking into account all option\n  settings, either defaults or job-specific ones. It reads the PPD\n  file assigned to the print queue, either a Foomatic-generated one or\n  a manufacturer-supplied PPD file of a PostScript printer, uses the\n  information to find the default option settings and to build the\n  renderer's (usually Ghostscript, \"cat\" for PostScript printers)\n  command line, and applies the user-supplied options. Then it builds\n  the renderer's command line and passes the data through it. If the\n  data is not PostScript or PDF, a pre-filter (\"a2ps\", \"enscript\",\n  \"mpage\", ...) is added.\n\n\n\nAbout the database\n------------------\n\nThe database is provided by the \"foomatic-db\" package, additional\ndatabase entries are in \"foomatic-db-nonfree\", drivers can also supply\nFoomatic XML files. \"foomatic-db\" is required for using the programs\nprovided by this package.\n\nThere is a $libdir, somewhere (usually\n/usr/share/foomatic/). Underneath $libdir there are (Install\n\"foomatic-db\" at first and then this package. Then the $libdir will be\nauto-detected):\n\n db/                             - the database\n db/oldprinterids                - translation table for old numerical\n\t\t\t\t   printer IDs and for printer IDs which\n\t\t\t\t   go changed\n db/kitload.log                  - list of third-party \"kit\" files, logged\n                                   by foomatic-kitload\n db/source/                      - \"source\" data, provided by humans, etc\n db/source/printer/\u003cpoid\u003e.xml    - printer-specific data, one per printer id\n db/source/driver/\u003cdriver\u003e.xml   - driver-specific data, one per driver name\n db/source/opt/\u003cidx\u003e.xml         - option data, one file per option\n db/source/PPD/                  - Ready-made PPD files, usually supplied by\n                                   printer manufacturers for their PostScript\n\t\t\t\t   printers.\n\nYou can edit the files whenever you want and regenerate the affected\nprinter queues with foomatic-configure, there is no on-disk cache, the\ndata is always directly derived from the source files. So your changes\nwill be taken into account without any special steps.\n\n\nFoomatic::DB API\n----------------\n\nThis API isn't required, now that the data is an an easy-to-process\nformat (nevermind the foomatic-configure language independent \"API\")\nfor heathen users of non-Perl languages, but even for such dogs it's\ninstructive to poke at how certain things are done:\n\nget_driverlist\nget_printerlist\nget_printers_for_driver\nget_drivers_for_printer\n\n  These all return lists of printer id's or driver names.  The\n  get_foo_for_bar methods accept a printer id or driver name as\n  appropriate; the frst two just return all and take no arguments.\n\nget_overview\nget_overview_xml\n\n  This returns an overview listing of all printers, with ids, makes,\n  models, functionaliy, drivers, etc.  The various flavors return a\n  Perl data structure or XML.\n\nget_makes\nget_models_by_make\n\n  These return makes and models lists.\n\nget_javascript2\n\n  This returns a JavaScript function that accepts two widget element\n  names.  If the first one is set to a value that euqals a known make,\n  then the second one's choices are replaced with a set of models\n  valued with printer IDs.  We use this to make a \"nested menu\" out of\n  two menu controls on a web page.\n\nget_printer_from_make_model\n\n  This returns a printer id from a make and model\n\nnormalize\nnormalizename\n\n  These are used for sorts to sort printer model names properly and\n  also to do searches for printer models/IDs. normalize makes the\n  input string all lower-case, turns a '+' tp 'plus', and removes all\n  non-alphanumeric characters. normalizename turns all groups of\n  digits to a zero-padded fixed-length number, so that printers with\n  the same product line name (like \"LaserJet\") and different model\n  numbers appear in correct numerical order. In addition,\n  normalizename also applies normalize.\n\nget_combo_data_xml\n\n  This returns the combined printer/driver data for a particular\n  combination.  Arguments are driver and printer id.\n\n  The \"combo\" operation is less trival than it looks; be careful when\n  messing with it. It took us hours to get right... Currently, it is\n  implemented in the foomatic-combo-xml.c C accelerator.\n\nget_printer_xml\nget_printer\nget_driver_xml\nget_driver\n\n  These return the information in the printer info or driver info\n  database files. The *_xml functions produce XML, the others Perl\n  data structures.\n\nfind_printer\n\n  This function returns Foomatic printer IDs to match a given search\n  term. The search term can be manufacturer and model, separated by a\n  space or a '|', an IEEE-1284 device ID of a printer, manufacturer,\n  model, Foomatic printer ID, or parts of any of the mentioned items.\n\ngetdat\n\n  This returns a Perl data structure of all the data for a given\n  printer/driver combo. It contains a description of printer\n  capabilities, all options, choices, and ranges valid for this\n  particular combo. It is used to build the PPD files, but can also\n  be used by Perl frontends. It takes driver and printer ID arguments;\n  just like get_combo_data_xml\n\ngetppd\n\n  This returns the spooler-independent PPD file for foomatic-rip and for \n  applications and clients. It takes no arguments; instead you must call \n  getdat first, and they'll then magically find that result. \n\ngetdocs\ngetexecdocs\nget_summarydocs\n\n  For some reason there are three functions which return documentation\n  about job options for particular printer/driver pairs. There's also a \n  fourth one inside foomatic-rip (invoked by the \"docs\" option).\n\n  These work the same way as getppd; you call getdat first.\n\n  Once, these worked if you called getdat with only a driver; in that\n  case it sort of documented it for all printers at once. This is\n  sort of incomplete, especially what with PJL arguments in the world.\n  Grant also probably broke it in the xml rewrite. Till has\n  rewritten getexecdocs to produce documentation for a given printer\n  driver pair, it provides the data presented on the \"Execution Details\"\n  pages of OpenPrinting.\n  \nget_libdir\n\n  Returns the library directory.\n\n\nDependencies\n------------\n\nBesides Perl and a C compiler with its standard libraries you will\nneed the libxml C library for XML handling and one of the tools\n\"wget\"/\"curl\".\n\nIn addition, you need the Foomatic database (\"foomatic-db\") and the\nFoomatic filters (\"foomatic-filters\") packages. It is recommended to\ninstall these packages before you install this package. Then the paths\nto their components get auto-detected during the build of this\npackage.\n\n\"wget\" (from www.gnu.org) is really a standard tool which nearly every\ndistribution includes.\n\nBecause libxml is also used by GNOME, it is probably also part of\nevery distribution of GNU/Linux or *BSD and one can also easily build\nit on any Unix-like operating system. If you distribution does not\nprovide libxml you can get libxml from\n\n   http://www.xmlsoft.org/\n\nIf your distribution contains libxml, note that besides the \"libxml\"\nor \"libxml2\" package you must install also a package with a name\n\"libxml-devel\" or \"libxml2-devel\" to be able to compile programs which\nuse libxml. This additional package contains the needed header files\nand \"xml(2)-config\", which tells the C compiler where it finds the\nheader files. If \"xml(2)-config\" or some header files in the packages\nof your distribution are missing, compile libxml from source.\n\nThe versions 1.8.17 and 2.4.19 of libxml are tested, both work, but\n1.8.17 requires that the XML files do not have leading blank\nlines. Use foomatic-fix-xml if you have such XML files (old or\nthird-party files).\n\nUsing libxml 2.x is highly recommended.\n\nYou need libxml 2.x, aclocal (in the \"automake\" package in some\ndistros), and autoconf when you want to compile Foomatic from the BZR\nrepository.\n\nSee the USAGE file for compilation details.\n\n\nData\n----\n\nThere are three main source datafiles (printers, drivers, and options;\nannotated examples:\n\n\nprinter/HP-LaserJet_4000.xml\n============================\n\n# The printer file contains information specific to a particular\n# printer.\n\n\u003cprinter id=\"printer/HP-LaserJet_4000\"\u003e\n\n# Make and model are not internationalized.  There will eventually be\n# an \"alias\" mechanism, but the need is different.\n\n  \u003cmake\u003eHP\u003c/make\u003e\n  \u003cmodel\u003eLaserJet 4000\u003c/model\u003e\n\n# According to the Adobe specifications for PPD files every PPD file\n# must contain a unique DOS-compatible file name (the \"*PCFileName\"),\n# a file name with an up to 8 characters log base name and an up to 3\n# characters long extension, and upper and lower case letters being\n# considered as equal. As every PPD file is for a printer/driver\n# combo, we let the first 6 characters being provided by the printer\n# entry:\n\n  \u003cpcmodel\u003eHPLJ4K\u003c/pcmodel\u003e\n\n# The first two characters should be the manufacturer prefix as listed\n# in Appendix D of Adobe's \"PostScript Printer Description (PPD) File\n# Format Specification Version 4.3\", available on\n\n# http://partners.adobe.com/public/developer/en/ps/5003.PPD_Spec_v4.3.pdf\n\n# Various stuff about the machine\n\n  \u003cmechanism\u003e\n\n# Printer types can be \u003claser /\u003e, \u003cled /\u003e, \u003cinkjet /\u003e, \u003cdotmatrix /\u003e,\n# \u003cimpact /\u003e, \u003csublimation /\u003e, \u003ctransfer /\u003e, \u003cthermal /\u003e. Other types\n# we have to add to the CGI script on OpenPrinting to make the web\n# interface displaying them properly.\n\n    \u003claser /\u003e\n\n# At some point we can make color be less of a boolean flag and more\n# of a section full of goodies.\n\n    \u003c!--not \"color\"--\u003e\n    \u003cresolution\u003e\n\n# In theory this is a list.  In practice We've only got one per\n# printer which is the maximum resolution the manufacturer claims for\n# this printer. Do not put empty tags (like \"\u003cx\u003e\u003c/x\u003e\" or \"\u003cx /\u003e\" here\n# if the resolution is not known. Leave out the tags (or the whole\n# \u003cresolution\u003e section).\n\n      \u003cdpi\u003e\n        \u003cx\u003e1200\u003c/x\u003e\n        \u003cy\u003e1200\u003c/y\u003e\n      \u003c/dpi\u003e\n    \u003c/resolution\u003e\n\n    \u003cconsumables\u003e\n\n# Information about ink, drums, etc.\n# The comments are supposed to be qualitative (\"Separate drum and\n# toner cartridges\")\n\n      \u003ccomments\u003e\n        \u003cen\u003etoner\u003c/en\u003e\n      \u003c/comments\u003e\n\n# There can be \u003cpartno\u003e12A1975\u003c/partno\u003e elements with manufacturer\n# part numbers for the various carts, etc it takes. Unfortunately,\n# this is not made use of, one could make a consumable database with\n# this for example.\n\n      \u003c!--one or more \"partno\" elements.--\u003e\n    \u003c/consumables\u003e\n  \u003c/mechanism\u003e\n\n  \u003curl\u003ehttp://www.pandi.hp.com/pandi-db/prod_info.show?model=C4118A\u0026amp;name=LaserJet4000\u003c/url\u003e\n\n# The lang section.  In practice this will be only minimally useful;\n# \n#  - Backends can pstops the ps down a level if needed\n#  - Backends know if pjl options apply\n#  - Backends can know if direct text printing will work\n#\n# Commonly used language tags: \u003cpcl level=\"x\" /\u003e, \u003cescp2 /\u003e, \u003cproprietary /\u003e\n\n  \u003clang\u003e\n    \u003cpostscript level=\"2\" /\u003e\n    \u003cpjl /\u003e\n    \u003ctext\u003e\n      \u003ccharset\u003eus-ascii\u003c/charset\u003e\n    \u003c/text\u003e\n  \u003c/lang\u003e\n\n# The autodetection stuff\n\n  \u003cautodetect\u003e\n\n# There are three ways to auto-detect a printer, via the parallel port\n# (\u003cparallel\u003e...\u003c/parallel\u003e), the USB (\u003cusb\u003e...\u003c/usb\u003e), or SNMP\n# (TCP/Socket-connected printer, \u003csnmp\u003e...\u003c/snmp\u003e). Through these\n# interfaces the printers report back an IEEE-1284-complient ID string\n# from which the fields \"MFG\" (\u003cmanufacturer\u003e...\u003c/manufacturer\u003e),\n# \"MDL\" (\u003cmodel\u003e...\u003c/model\u003e), \"DES\" (\u003cdescription\u003e...\u003c/description\u003e),\n# and \"CMD\" (\u003ccommandset\u003e...\u003c/commandset\u003e) are used. The string itself\n# can be put between \u003cieee1284\u003e...\u003c/ieee1284\u003e tags, but all items\n# which are not constant for all printers of this model, as the serial\n# number (\"SERN:...;\") and the device status (\"VSTATUS:...;\") have to\n# be removed here. As the ID string is usually the same for all\n# detection methods, one can put the entries between\n# \u003cgeneral\u003e...\u003c/general\u003e tags, then the \u003cparallel\u003e...\u003c/parallel\u003e,\n# \u003cusb\u003e...\u003c/usb\u003e, and \u003csnmp\u003e...\u003c/snmp\u003e are only used for\n# differences to the data between the \u003cgeneral\u003e...\u003c/general\u003e tags. A\n# complete entry could look like:\n#\n#  \u003cautodetect\u003e\n#    \u003cgeneral\u003e\n#      \u003cieee1284\u003eMFG:HEWLETT-PACKARD;MDL:DESKJET 600;CMD:MLC,PCL,PML;CLASS:PRINTER;DESCRIPTION:Hewlett-Packard DeskJet 600;\u003c/ieee1284\u003e\n#      \u003ccommandset\u003eMLC,PCL,PML\u003c/commandset\u003e\n#      \u003cdescription\u003eHewlett-Packard DeskJet 600\u003c/description\u003e\n#      \u003cmanufacturer\u003eHEWLETT-PACKARD\u003c/manufacturer\u003e\n#      \u003cmodel\u003eDESKJET 600\u003c/model\u003e\n#    \u003c/general\u003e\n#  \u003c/autodetect\u003e\n#\n\n# If you use CUPS, you get the device IDs of all locally connected\n# (USB, parallel) printers and of printers in the local network by\n# running:\n\nlpinfo -l -m\n\n# On Linux you find this info for the parallel ports (/dev/lp\u003cN\u003e, \u003cN\u003e\n# = 0, 1, 2, ...) in the files\n#\n#   /proc/sys/dev/parport/parport\u003cN\u003e/autoprobe*\n#\n# for the USB under Linux it is more complicated, easiest is to use a little\n# Perl script, called \"getusbprinterid.pl\":\n# You need to find the IOCTL call value to pass to the perl ioctl function.\n# Here is a little C program that does this. This is easier than trying to\n# use p2h and convert the *.h files to perl.\n\n# --------------------------------------------------------------------------\n#  /*\n#       print the IOCTL call value for printer information\n#  */\n#  #include \u003cstdio.h\u003e\n#  #include \u003csys/ioctl.h\u003e\n#  /* From the /usr/src/linux\u003cversion\u003e/drivers/usb/printer.c */\n#  #define DRIVER_VERSION \"v0.11\"\n#  #define DRIVER_AUTHOR \"Michael Gee, Pavel Machek, Vojtech Pavlik, Randy Dunlap, Pete Zaitcev, David Paschal\"\n#  #define DRIVER_DESC \"USB Printer Device Class driver\"\n#  \n#  #define USBLP_BUF_SIZE      8192\n#  #define DEVICE_ID_SIZE      1024\n#  \n#  /* ioctls: */\n#  #define LPGETSTATUS     0x060b      /* same as in drivers/char/lp.c */\n#  #define IOCNR_GET_DEVICE_ID     1\n#  #define IOCNR_GET_PROTOCOLS     2\n#  #define IOCNR_SET_PROTOCOL      3\n#  #define IOCNR_HP_SET_CHANNEL        4\n#  #define IOCNR_GET_BUS_ADDRESS       5\n#  #define IOCNR_GET_VID_PID       6\n#  /* Get device_id string: */\n#  #define LPIOC_GET_DEVICE_ID(len) _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)\n#  /* The following ioctls were added for http://hpoj.sourceforge.net */\n#  /* (HPOJ is replaced by HPLIP, http://hplipopensource.com/): */\n#  /* Get two-int array:\n#  * [0]=current protocol (1=7/1/1, 2=7/1/2, 3=7/1/3),\n#  * [1]=supported protocol mask (mask\u0026(1\u003c\u003cn)!=0 means 7/1/n supported): */\n#  #define LPIOC_GET_PROTOCOLS(len) _IOC(_IOC_READ, 'P', IOCNR_GET_PROTOCOLS, len)\n#  /* Set protocol (arg: 1=7/1/1, 2=7/1/2, 3=7/1/3): */\n#  #define LPIOC_SET_PROTOCOL _IOC(_IOC_WRITE, 'P', IOCNR_SET_PROTOCOL, 0)\n#  /* Set channel number (HP Vendor-specific command): */\n#  #define LPIOC_HP_SET_CHANNEL _IOC(_IOC_WRITE, 'P', IOCNR_HP_SET_CHANNEL, 0)\n#  /* Get two-int array: [0]=bus number, [1]=device address: */\n#  #define LPIOC_GET_BUS_ADDRESS(len) _IOC(_IOC_READ, 'P', IOCNR_GET_BUS_ADDRESS, len)\n#  /* Get two-int array: [0]=vendor ID, [1]=product ID: */\n#  #define LPIOC_GET_VID_PID(len) _IOC(_IOC_READ, 'P', IOCNR_GET_VID_PID, len)\n#  \n#  \n#  int main( int argc, char *argv, char *envp[] )\n#  {\n#   int len = 1024;\n#   int v;\n#   /* _IOC(), _IOC_READ as defined in /usr/include/asm/ioctl.h\n# LPIOC_GET_DEVICE_ID(len) = _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)\n#   */\n#   v = LPIOC_GET_DEVICE_ID(len);          printf(\"$LPIOC_GET_DEVICE_ID = 0x%08x;\\n\", v );\n#   v = LPIOC_GET_BUS_ADDRESS(len);        printf(\"$LPIOC_GET_BUS_ADDRESS = 0x%08x;\\n\", v );\n#   v = LPIOC_GET_VID_PID(len);            printf(\"$LPIOC_GET_VID_PID = 0x%08x;\\n\", v );\n#   return(0);\n#  }\n#  \n#     \n# save this to a file, say getv.c, compile and run it, and you get an output\n$ like this:\n#  $LPIOC_GET_DEVICE_ID = 0x84005001;\n#  $LPIOC_GET_BUS_ADDRESS = 0x84005005;\n#  $LPIOC_GET_VID_PID = 0x84005006;\n\n\n\n# Here is the getusbprinterid.pl PERL program to get the usb information\n#    \n#\t!/usr/bin/perl\n#\topen FILE, \"$ARGV[0]\" or die \"cannot open $ARGV[0]\";\n#\tmy $result;\n#\t# len = 1024\n#\t# LPIOC_GET_DEVICE_ID(len) = _IOC(_IOC_READ, 'P', IOCNR_GET_DEVICE_ID, len)\n#\t# _IOC(), _IOC_READ as defined in /usr/include/asm/ioctl.h\n#\t$LPIOC_GET_DEVICE_ID = 0x84005001;\n#\t$LPIOC_GET_BUS_ADDRESS = 0x84005005;\n#\t$LPIOC_GET_VID_PID = 0x84005006;\n#\t\n#\tioctl(FILE, $LPIOC_GET_DEVICE_ID , $result) or die;\n#\t# Cut resulting string to its real length\n#\tmy $length = ord(substr($result, 1, 1)) + (ord(substr($result, 0, 1)) \u003c\u003c 8);\n#\t$result = substr($result, 2, $length-2);\n#\t# Remove non-printable characters\n#\t$result =~ tr/[\\x0-\\x1f]/\\./;\n#\tprint \"DeviceID $result\\n\";\n#\t\n#\t$result = pack(\"LL\",0);\n#\tioctl(FILE, $LPIOC_GET_BUS_ADDRESS , $result) or die;\n#\tmy( $v1, $v2 ) = unpack(\"LL\", $result );\n#\tprint \"Bus '$v1', Device '$v2'\\n\";\n#\t\n#\t$result = pack(\"LL\",0);\n#\tioctl(FILE, $LPIOC_GET_VID_PID, $result) or die;\n#\tmy( $v1, $v2 ) = unpack(\"LL\", $result );\n#\tprint \"Vendor '$v1', Product '$v2'\\n\";\n#\t\n#\tclose FILE;\n#\t\n#    \n# --------------------------------------------------------------------------\n\n# Running the program with \"perl getusbprinterid.pl /dev/usb/lp0\" returns the\n# ID string of the device on /dev/usb/lp0.\n# For example: perl getusbprinter.pl /dev/usb/lp0  \n#  DeviceID MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:\\\n#    HP LaserJet 2200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 2200;\\\n#    MEM:8MB;OPTRAY:250Sheets\n#  Bus '2', Device '2'\n#  Vendor '1008', Product '535'\n#\n# (lines broken for clarity)\n\n\n    \u003c!--no known parport probe information--\u003e\n  \u003c/autodetect\u003e\n\n# Our grading system.  It's US-style letter grades A, B, D, and F,\n# which the website shows as \"Perfectly\", \"Mostly\", \"Partially\" and\n# \"Paperweight\" .\n# THERE IS NO `C'!!!\n\n  \u003cfunctionality\u003eA\u003c/functionality\u003e\n\n# Arguably, the scores should live with the printer/driver association\n# and not on the printer, but then it's a big hassle to figure out if\n# a printer works... So the score is the one reached with the driver\n# working best, the \"recommended\" driver.\n\n# There's a spot for this \"recommended\" driver, usually the driver\n# which gives the maximum output quality. It is for user information\n# on the web site, but newbie-friendly printer setup GUIs should use\n# it, too. system-config-printer, printer setup tool of Fedora/Red\n# Hat, Ubuntu, and Mandriva Linux makes use of it, also the former\n# printerdrake of Mandriva Linux.\n\n  \u003cdriver\u003ePostscript-HP\u003c/driver\u003e\n\n# The following optional section describes with which drivers this\n# printer works. A valid printer/driver pair can be defined by either\n# adding the printer to the driver's printer list (the way how it\n# worked all the time) but also by adding the driver to the printer's\n# driver list. This way a printer can get associated with a driver for\n# which there is no driver XML file and a driver can list a supported\n# printer which is not in the printer XML database. For providing a\n# PPD file both printer and driver XML files must exist, but it is not\n# important in which of the two the printer/driver relationship is\n# defined.\n\n# The driver list in the printer XML files was introduced for once\n# defining links to ready-made PPD files (relative paths without \"/\",\n# \"http:\", \"https:\", or \"ftp:\" in the beginning are relative to\n# $libdir/db/source/, absolute links can point to external sites, as\n# for example the site of a printer manufacturer, but they must always\n# provide the non-interactive download of the PPD file, for example\n# via \"wget\") and second, listing the supported drivers for\n# visitor-contributed printer entries (from web input form). The\n# comments section is for adding comments specific to the\n# printer/driver combo. As it is human-readable it is\n# internationalized. Each driver entry here must have a driver ID. PPD\n# file link and comment are optional.\n\n  \u003cdrivers\u003e\n    \u003cdriver\u003e\n      \u003cid\u003ePostscript-HP\u003c/id\u003e\n      \u003cppd\u003ePPD/HP/HP_LaserJet_4000_Series.ppd\u003c/ppd\u003e\n      \u003ccomments\u003e\u003cen\u003e...\u003c/en\u003e\u003c/comments\u003e\n    \u003c/driver\u003e\n  \u003c/drivers\u003e\n\n\n# The \u003cunverified /\u003e tag marks entries which are entered by visitors\n# via the printer input form on the OpenPrinting web site. It does not\n# appear in approved entries (= all entries in the BZR repository of\n# the foomatic-db package).\n\n  \u003c!--not \"unverified\"--\u003e\n\n# If there is a web site with additional interesting info about this\n# printer, it can be mentioned in the entry by putting it between\n# \u003ccontrib_url\u003e...\u003c/contrib_url\u003e tags,\n\n  \u003c!--no \"contrib_url\"--\u003e\n\n# The regular notes section.  The allowed tags are: \u003cp\u003e, \u003ca\n# href=\"foobar\"\u003e \u003c/a\u003e and many other simple tags (\u003cb\u003e, \u003ci\u003e, \u003ctt\u003e,\n# ...). Note that to distinguish what is XML and what is the embedded\n# HTML, the following replacements have to be made:\n#\n#   \u003c --\u003e \u0026lt;\n#   \u003e --\u003e \u0026gt;\n#   \" --\u003e \u0026quot;\n#   ' --\u003e \u0026apos;\n#   \u0026 --\u003e \u0026amp;\n#\n\n  \u003ccomments\u003e\n    \u003cen\u003e\n    I don\u0026apos;t believe this:\u0026lt;p\u0026gt;\n\n    \u0026lt;i\u0026gt;1200x1200 dpi only possible with Windows drivers,\n    600x600 can be reached w/o particular software.\n    The difference is visible, but only slightly, so\n    the Functionality got \u0026quot;Mostly\u0026quot;\u0026lt;p\u0026gt;\u0026lt;/i\u0026gt;\u0026lt;p\u0026gt;\n\n    Do the following:\u0026lt;p\u0026gt;\n\n    Set the resolution on the front panel to \u0026quot;Prores 1200\u0026quot;, not\n    to \u0026quot;Fastres 1200\u0026quot;. When you use CUPS with HPs PPD file, turn\n    off \u0026quot;Fastres 1200\u0026quot; in the printer configuration\n    options.\u0026lt;p\u0026gt;\n\n    Try the generic PostScript PPD file which comes with KUPS 1.0 or newer.\n    \u003c/en\u003e\n  \u003c/comments\u003e\n\u003c/printer\u003e\n\n\ndriver/md2k.xml\n===============\n\nThe driver files contain information about drivers.  There are a few\nthings, but the two biggies are the prototype and the printers list\n\n\u003cdriver id=\"driver/md2k\"\u003e\n \u003cname\u003emd2k\u003c/name\u003e\n\n# According to the Adobe specifications for PPD files every PPD file\n# must contain a unique DOS-compatible file name (the \"*PCFileName\"),\n# a file name with an up to 8 characters log base name and an up to 3\n# characters long extension, and upper and lower case letters being\n# considered as equal. As every PPD file is for a printer/driver combo,\n# we let the last 2 characters being provided by the driver entry:\n\n \u003cpcdriver\u003eM2\u003c/pcdriver\u003e\n\n# The drivers listed by the OpenPrinting database are usually not\n# developed by OpenPrinting.  Most free software printer drivers come\n# from independent projects, initiated by peopke who want to get their\n# printers to work under Linux, some other drivers come from the\n# printer manufacturers. So even if OpenPrinting hosts a downloadable\n# package of the driver the development of the driver is not part of\n# OpenPrinting. Therefore every driver entry has to contain a\n# reference to the developers of the driver, where the driver can be\n# actually downloaded. The appropriate link goes into the \u003curl\u003e tag:\n\n \u003curl\u003ehttp://plaza26.mbn.or.jp/~higamasa/gdevmd2k/\u003c/url\u003e\n\n# The driver XML files can contain the following tags to describe the\n# driver's properties, so that a user can easily find the driver which\n# is most suitable for him. The properties are shown in the gray\n# driver info boxes on the OpenPrinting web site and they are also\n# supposed to be shown by printer setup tools when they offer to\n# download a driver from OpenPrinting. It is especially important to\n# supply them if a downloadable driver package or PPD files are\n# supplied.\n\n# Supplier's name, internationalization (with \u003cen\u003e...\u003c/en\u003e\u003cde\u003e...\u003c/de\u003e...)\n# optional\n\n#   \u003csupplier\u003eSpliX project\u003c/supplier\u003e\n\n# Does the driver come from the printer's manufacturer or from a third\n# party. The third form tells also the manufacturer names of the\n# printers which are from the manufacturer which developed the\n# driver. If there are also printers from other manufacturers\n# supported (like for the PCL driver HPIJS) then the OpenPrinting web\n# site does not show this driver as manufacturer-supplied on the pages\n# of the printers of other manufacturers.\n\n#   \u003cthirdpartysupplied /\u003e   OR   \u003cmanufacturersupplied /\u003e   OR\n#   \u003cmanufacturersupplied\u003eHP|Apollo\u003c/manufacturersupplied\u003e\n\n# License name. Here should be put the common short name or\n# abbreviation if the license is one of the common free software\n# licenses. Otherwise it should contain something short and\n# descriptive, for non-free drivers simply \"Commercial\". The license\n# name can be internationalized with language tags\n# (\u003cen\u003e...\u003c/en\u003e\u003cde\u003e...\u003c/de\u003e...).\n\n#   \u003clicense\u003eGPL\u003c/license\u003e\n\n# The license text does not need to be supplied for common free\n# software licenses. It should be supplied if:\n#\n#  - The license is not free (\u003cnonfreesoftware /\u003e tag set)\n#  - The driver has patent issues (\u003cpatents /\u003e tag set, describe the\n#    patent issues here in that case)\n#  - The license of the driver is free but none of the common licenses\n#    (\u003cnonfreesoftware /\u003e tag not set)\n\n#   \u003clicensetext\u003e\n#    \u003cen\u003e\n#      ...\n#    \u003c/en\u003e\n#   \u003c/licensetext\u003e\n\n# License texts can also be linked from external sites:\n\n#   \u003clicensetext\u003e\n#    \u003cen url=\"http://www.laserstar.com/licenses/en/gl-series-eula.txt\" /\u003e\n#    \u003cde url=\"http://www.laserstar.com/licenses/de/gl-series-eula.txt\" /\u003e\n#    ...\n#   \u003c/licensetext\u003e\n\n# License texts have to be given always as plain text, UTF-8-encoded.\n\n# Mark with this tag whether the driver is non-free software\n\n#   \u003cnonfreesoftware /\u003e\n\n# All driver entries without this tag are considered to be free\n# software.\n\n# This tag tells whether there are any patent issues with the driver\n\n#   \u003cpatents /\u003e\n\n# The absence of the tag tells that the driver is free of patent\n# issues.\n\n# If a driver entry provides a \u003clicensetext\u003e and is \u003cnonfreesoftware\n# /\u003e or with \u003cpatents /\u003e printer setup tools which download this\n# driver are supposed to present the license text and ask the user\n# whether he agrees with it.\n\n# Printer manufacturers could want to package their drivers for\n# different market regions (Europe, Asia/Pacific, Americas, ...) as\n# the markets demand different capabilities of printer drivers and\n# different user-settable options (CJK-language-related stufff for\n# example). So there could even be two different driver flavors for\n# the same printer but adapted to different regions. To express these\n# driver properties there are special tags.\n\n# For each flavor of the driver a separate driver entry (driver XML\n# file) has to be supplied. There is no requirement of certain\n# properties of the driver flavors to be equal or not. Especially the\n# printer lists can contain printers which are not in all flavors, for\n# example if printers are only sold in certain regions. To mark which\n# entries are belonging together one adds a group tag to each XML\n# file, with the same group name, but the name must be different to\n# the names of all already existing groups. A locales tag contains all\n# language/country codes for which the driver flavor is intended:\n\n#   \u003cgroup\u003eepson-inkjet\u003c/group\u003e\n#   \u003clocales\u003ede en_UK en_IE fr_FR es_ES\u003c/locales\u003e\n\n# The codes in the locales tags should be different for the group\n# members, to allow to automatically select the most suitable flavor\n# if the detected printer is supported by more than one flavor.\n\n# For downloadable drivers support contacts should be given, so that\n# users get informed before they do the download and do not complain\n# at their OS distribution vendor if the driver downloaded from\n# OpenPrinting does not work. The human-readable string for the\n# support contact can be internationalized with language tags\n# (\u003cen\u003e...\u003c/en\u003e\u003cde\u003e...\u003c/de\u003e...).\n\n#   \u003csupportcontacts\u003e\n#    \u003csupportcontact level=\"voluntary\" url=\"http://sourceforge.net/forum/?group_id=175815\"\u003eSpliX forum at SourceForge\u003c/supportcontact\u003e\n#    \u003csupportcontact level=\"commercial\" url=\"http://www.laserstar.com/support/\"\u003eLaserStar Support\u003c/supportcontact\u003e\n#   \u003c/supportcontacts\u003e\n\n# This is an internationalized short description of the driver,\n# typically one line, to be used in the gray driver info boxes, in the\n# driver overview list, and also by printer setup tools. If a driver\n# entry is for a development version of a driver, tell it here, as the\n# long description is not shown everywhere.\n\n#   \u003cshortdescription\u003e\n#    \u003cen\u003e\n#     Driver for Samsung SPL2 (ML-1710, ...) and SPLc (CLP-500, ...) laser\n#     printers\n#    \u003c/en\u003e\n#   \u003c/shortdescription\u003e\n\n# If there are downloadable packages for this driver entry on the\n# OpenPrinting web site, a \u003cpackages\u003e section has to be supplied. This\n# tag tells which package files on the OpenPrinting web server belong\n# to this driver or on which external server to find packages for this\n# driver. It also allows assigning files or locations to different\n# components of this driver and to assign scopes to them. Scopes can\n# be: \"general\", \"gui\", \"printer\", \"scanner\", \"fax\", ... Uses the\n# \"general\" scope if packages are not split. Wild cards are the same\n# as used for file masks in the shell (NOT regular expressions). They\n# must match both Debian and RPM package file names. Note that between\n# file name and version number is a \"-\" for RPMs and a \"_\" for Debian\n# packages.\n\n#   \u003cpackages\u003e\n#    \u003cpackage scope=\"general\"\u003e*splix[_-]1.[0-9].[0-9]*\u003c/package\u003e\n#   \u003c/packages\u003e\n\n# It is possible to give absolute paths which can point to external\n# sites, as for example the site of a printer manufacturer, so that\n# the package can be hosted there but auto-downloaded via\n# OpenPrinting. Important is that these packages are auto-downloadable\n# LSB packages and that a non-interactive download is provided (should\n# also work with utilities like \"wget\"). Licenses which the users have\n# to agree on have to get supplied in the driver XML file. Printer\n# setup tools are supposed to ask the user for agreeing if the driver\n# is marked as non-free or with patent issues.\n\n# Example for packages provided by an external site:\n\n#   \u003cpackages\u003e\n#    \u003cpackage scope=\"general\" fingerprint=\"http://download.example.com/printerdrivers/gpg/key-fingerprint.txt\"\u003ehttp://download.example.com/printerdrivers/RPMS/i486/*laserstar*;http://download.example.com/printerdrivers/RPMS/x86_64/*laserstar*;http://download.example.com/printerdrivers/debian/dists/lsb3.2/main/binary-i386/*laserstar*;http://download.example.com/printerdrivers/debian/dists/lsb3.2/main/binary-amd64/*laserstar*\u003c/package\u003e\n#   \u003c/packages\u003e\n\n# Note that more than one mask can be supplied separating them with\n# semicolons (\";\").\n\n# The masks with absolute paths must match all package files, of all\n# architectures (usually i386/i486 and amd64/x86_64) and all package\n# systems (RPM and Debian). Use more than one mask if needed. On your\n# server each directory with package files inside must be browsable,\n# so that a client can expand the wildcards. In addition the packages\n# itself need to be readable for everyone so that they can get\n# downloaded.\n\n# Note also that the packages on the external server must be in\n# regular package repositories, so that automatic updates with the\n# package manager tools provided by the user's Linux distribution\n# (currently apt, yum, and zypper) can be performed. The configuration\n# data for the local tools is derived from the actual file locations,\n# which get determined by the masks.\n\n# Important is also that with paths (absolute starting with \"http://\",\n# \"https://\", or \"ftp://\" and relative simply having at least a slash\n# somewhere) wildcards can only be used after the last slash (\"/\"). So\n# wildcards are only allowed for the file name and not for the\n# directory names.\n\n# If the packages are signed, all packages of the same \u003cpackage\u003e entry\n# should be signed with the same key and the key should be registered\n# on the key server network. The key fingerprint should be made\n# available as a text file on the web site of the driver issuer and\n# the site should be with an SSL certificate which has been signed by\n# an official registrar. The \"fingerprint=...\" parameter should then\n# provide the link to the file with the key fingerprint. The link must\n# be an \"https://...\" URL and point to a file on a server of the\n# driver issuer. Packages must be signed for fully automatic upload by\n# default on Linux distributions. See also\n\n# https://www.linuxfoundation.org/collaborate/workgroups/openprinting/writingandpackagingprinterdrivers\n\n# The \u003cfunctionality\u003e section should make it easier for a user to\n# compare different drivers by giving some technical properties and\n# ratings (0...100) for common document types, system load, and\n# execution speed. The higher the number, the better the driver\n# performs here. It is not required to supply all items. Items can be\n# left out or can stay empty. \u003cfunctionality\u003e sections of the same\n# format can also be used in the \u003cprinter\u003e entries in the \u003cprinters\u003e\n# list, to describe exceptions for particular printers. If an item is\n# left out or empty there, the appropriate item in the general\n# \u003cfunctionality\u003e section is used, so only the items which are\n# different for the given printer need to be listed.\n\n#   \u003cfunctionality\u003e\n#    \u003cmaxresx\u003e1200\u003c/maxresx\u003e\n#    \u003cmaxresy\u003e1200\u003c/maxresy\u003e\n#    \u003ccolor /\u003e   OR   \u003cmonochrome /\u003e\n#    \u003ctext\u003e100\u003c/text\u003e\n#    \u003clineart\u003e100\u003c/lineart\u003e\n#    \u003cgraphics\u003e100\u003c/graphics\u003e\n#    \u003cphoto\u003e80\u003c/photo\u003e\n#    \u003cload\u003e50\u003c/load\u003e\n#    \u003cspeed\u003e90\u003c/speed\u003e\n#   \u003c/functionality\u003e\n\n# Not all tags are required here, if the valur for a tag is not known,\n# the tag has to be left out. Do not put empty tags (like\n# \"\u003ctext\u003e\u003c/text\u003e\" or \"\u003ctext /\u003e\" here.\n\n# The \u003cexecution\u003e section describes everything needed to execute the\n# driver.\n\n \u003cexecution\u003e\n\n# Sometimes it is possible that a driver depends on another driver,\n# for example a manufacturer publishes a core driver which is\n# completely free software and supports most of their printer. In\n# addition, he publishes closed-source plugins for the core driver to\n# support additional printers where they cannot open the driver code\n# for IP reasons. He wants to link in all his driver packages for\n# automatic download with the \u003cpackages\u003e tags. To make everything work\n# correctly he creates one driver entry for the core driver and one\n# for each plugin. The printers which do not need the plugin get\n# listed as supported by the core driver, the printers needing a\n# plugin are listed as supported by the plugin. To avoid that then\n# only a plugin gets automatically downloaded one adds a \u003crequires\u003e\n# tag to each entry of a plugin, to the beginning of the \u003cexecution\u003e\n# section:\n\n#    \u003crequires version=\"\u0026gt;= 5.0.1\"\u003egutenprint\u003c/requires\u003e\n#    \u003crequires version=\"\u0026gt;= 2.7.10\"\u003ehpijs\u003c/requires\u003e\n \n# The version attribute is optional, without, every version is\n# accepted. Optional relationships (\u003e=, \u003c=, =, \u003c, \u003e) allow to not only\n# accept the given version. The '\u003e´ and '\u003c' have to be replaced by the\n# appropriate XML entities, as described earlier here for other text\n# in the XML files. More than one \u003crequires\u003e tag is allowed.\n\n# Driver types are \n#\n#  \u003cghostscript /\u003e : The driver code is compiled into Ghostscript\n#\n#  \u003cijs /\u003e :         IJS plug-in. These are raster drivers which connect\n#                    to the IJS interface of the renderer, usually of \n#                    Ghostscript but also of pdftoijs or others. The\n#                    interface is based on pipes and is bi-directional.\n#                    It makes the driver independent of the renderer.\n#\n#  \u003ccups /\u003e :\t     CUPS Raster driver. The raster driver standard\n#                    introduced by CUPS. The renderer generates the CUPS\n#\t\t     Raster format, a bitmap format optimized for printing,\n#\t\t     and it gets piped into the driver.\n#\n#  \u003copvp /\u003e :        OpenPrinting Vector driver. DLL and IPC interface for\n#                    plugging printer drivers into the renderer. This is\n#                    the only solution of mudular printer drivers for high-\n#                    level graphics (vector) PDLs.\n#\n#  \u003cuniprint /\u003e :    A uniprint driver, consisting of one or more .upp\n#                    files for Ghostscript.\n#\n#  \u003cfilter /\u003e :      The driver code is a separate executable and the \n#                    driver does not fit into the groups listed above, \n#                    usually either a filter which converts generic \n#                    bitmap output of Ghostscript to the printer's \n#                    language, or a wrapper around Ghostscript.\n#\n#  \u003cpostscript /\u003e :  A driver which has PostScript as output (for \n#                    PostScript printers). It usually does not call\n#                    Ghostscript but only applies the user's option\n#                    settings to the data stream. But Ghostscript can\n#                    be called here, too, as for downgrading to a lower\n#                    PostScript level or for handling PDF input.\n#\n# The driver type only provides information for the web pages (or\n# driver auto-download facilities of printer setup tools), it is not\n# used when generating PPD files.\n\n   \u003cghostscript /\u003e\n\n# The driver's \u003cexecution\u003e section can also contain a\n#\n# \u003cnopjl /\u003e\n#\n# which suppresses the usage of PJL options (options which send PJL\n# commands to the printer). This is done with drivers where the driver\n# itself already produces a PJL header and where the PJL options\n# defined for the supported printers would badly interfere. In most\n# cases this is not needed, as foomatic-rip merges the PJL headers of\n# the driver and of the PJL options.\n\n# And the driver's \u003cexecution\u003e section can also contain a\n#\n# \u003cnopageaccounting /\u003e\n#\n# This suppresses the inserting of page accounting code (for CUPS)\n# into the PostScript data stream. Some drivers lead to unexpected\n# behavior with that. Especially for the generic PostScript drivers\n# (which do not use Ghostscript in most cases) the accounting code\n# should not be inserted.\n\n# The prototype defines what command the backends run to drive this\n# printer. It must take at least PostScript, preferably both PDF and\n# PostScript on stdin and generate the printer's native language on\n# stdout. Various %A, %B, etc substitution \"spots\" are specified; this\n# is where substition options will be placed.\n\n  \u003cprototype\u003egs -q -dBATCH -dSAFER -dQUIET -dNOPAUSE -sDEVICE=md2k%A%Z -sOutputFile=- -\u003c/prototype\u003e\n \u003c/execution\u003e\n \u003ccomments\u003e\n  \u003cen\u003e\n    Part of the gdevmd2k-0.2a package by Shinya Umino.  The web page and\n    documentation are in Japanese.\n    \u0026lt;a href=\"/clippings/MD5000-translation.txt\"\u0026gt;Here\u0026lt;/a\u0026gt;\n    is an English translation of the driver's web page, and \u0026lt;a\n    href=\"/clippings/alpsmd.txt\"\u0026gt;here\u0026lt;/a\u0026gt; is the README from the\n    driver package.\n  \u003c/en\u003e\n \u003c/comments\u003e\n\n# if there is only a \u003cprototype\u003e and not a \u003cprototype_pdf\u003e entry,\n# foomatic-rip will feed both PostScript and PDF into the command line\n# defined with \u003cprototype\u003e, otherwise for PostScript input the\n# \u003cprototype\u003e command line is used and for PDF input the\n# \u003cprototype_pdf\u003e command line. Both are defined the same way and the\n# same command line snippets are inserted from the option settings.\n\n# If there is only a \u003cprototype\u003e defined, PDF will only be fed in if\n# the command line begins with \"gs \" (this means Ghostscript is called\n# and Ghostscript understands both PostScript and PDF) and there are\n# no options based on inserting active PostScript code into the input\n# data stream. Otherwise foomatic-rip converts PDF input to PostScript\n# at first and feeds the PostScript through the command line.\n\n# The printer list is a simple list of printers that this driver works\n# with. Alternatively, one can tell that a given printer works with a\n# given driver also by a \u003cdrivers\u003e list in the printer's XML file (see\n# above).\n\n \u003cprinters\u003e\n  \u003cprinter\u003e\n   \u003cid\u003eprinter/Alps-MD-1000\u003c/id\u003e\u003c!-- Alps MD-1000 --\u003e\n  \u003c/printer\u003e\n  \u003cprinter\u003e\n   \u003cid\u003eprinter/Alps-MD-1300\u003c/id\u003e\u003c!-- Alps MD-1300 --\u003e\n  \u003c/printer\u003e\n  \u003cprinter\u003e\n   \u003cid\u003eprinter/Alps-MD-2000\u003c/id\u003e\u003c!-- Alps MD-2000 --\u003e\n  \u003c/printer\u003e\n  \u003cprinter\u003e\n   \u003cid\u003eprinter/Alps-MD-4000\u003c/id\u003e\u003c!-- Alps MD-4000 --\u003e\n  \u003c/printer\u003e\n \u003c/printers\u003e\n\u003c/driver\u003e\n\n# In the printer list it is also possible to place comments or\n# exceptions in the driver's functionality (see above) specific to a\n# certain printer/driver pair:\n\n#  \u003cprinter\u003e\n#   \u003cid\u003eprinter/HP-LaserJet_4050\u003c/id\u003e\u003c!-- HP LaserJet 4050 --\u003e\n#   \u003ccomments\u003e\n#    \u003cen\u003eto 1200dpi\u003c/en\u003e\n#   \u003c/comments\u003e\n#   \u003cfunctionality\u003e\n#    \u003cmonochrome /\u003e\n#   \u003c/functionality\u003e\n#  \u003c/printer\u003e\n\n# Note that printer/driver relationships can also be expressed by\n# adding the driver to the \u003cdrivers\u003e lists of the appropriate printer\n# XML files.\n\n\nsource/opt/2.xml\n================\n\n# Every option exists independently from printers or drivers, because\n# they might apply to arbitrary combinations of printers and/or\n# drivers.  In practice, some drivers have wholly unique options\n# (gutenprint for example), while others (lots of generic basic\n# Ghostscript drivers, for example) share some options.\n\n\u003coption type=\"enum\" id=\"opt/2\"\u003e\n\n# Options are of a type \"enum\", \"bool\", \"int\", \"float\", \"string\", or\n# \"password\", options have an ID.  The id is also the filename.\n\n# The shortname is a spaceless short name for the thing.  It must not\n# contain / or : (otherwise it will not be handled correctly in PPD\n# files). It should be one of the standard Adobe PPD option names if\n# apropriate\n\n  \u003carg_shortname\u003e\n\n# Various things here, and all \u003ccomments\u003e, are internationalized.\n# They take the usual posix locale codes in the form xx[_YY], where xx\n# is a two-letter iso language code, and YY is two-letter country code\n# to distinguish differing national dialects.\n#\n# Generally the national dialects won't be very common or necessary\n# here.  The backends currently require that \u003cen\u003e content be provided.\n\n   \u003cen\u003ePageSize\u003c/en\u003e\u003c!-- backends only know \u003cen\u003e shortnames! --\u003e\n  \u003c/arg_shortname\u003e\n\n# The longname is a short phrase describing the thing in more detail\n# GUI tools usually show longnames\n\n  \u003carg_longname\u003e\n   \u003cen\u003ePage Size\u003c/en\u003e\n  \u003c/arg_longname\u003e\n\n# The \u003ccomments\u003e are used to form documentation.  In theory these can\n# become man pages or the like. Example:\n\n#   \u003ccomments\u003e\n#    \u003cen\u003e\n#     This option allows the user to get a lighter or darker printout, but\n#     keeping totally black areas black and not making white areas gray.\n#    \u003c/en\u003e\n#   \u003c/comments\u003e\n\n  \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n       it should be treated as documentation for the user. --\u003e\n\n# The execution section describe how the backend should execute this\n# option. The order and spot apply to the *driver*'s prototype for\n# \u003carg_substitution /\u003e (once called commandline) style options, or\n# just the order applies for \u003carg_postscript /\u003e and \u003carg_pjl /\u003e\n# options. The order and the \u003carg_section\u003e go into the \"*OrderDependency\"\n# line of the appropriate option entry in the PPD file, for this example\n# one would get\n\n#    *OrderDependency: 100 DocumentSetup *PageSize\n\n# When no \u003carg_section\u003e is given, \"AnySetup\" is used as a default.\n\n# For \u003carg_substitution /\u003e options the \u003carg_proto\u003e is inserted into\n# the driver's command line, at the spot (e. g. \"%A\") whose letter is\n# given between the \u003carg_spot\u003e...\u003c/arg_spot\u003e tags, the \u003carg_proto\u003e of\n# an \u003carg_postscript /\u003e option is a snippet of PostScript code which\n# is inserted into the PostScript data stream of the job, for\n# DSC-conforming PostScript into the section specified with\n# \u003carg_section\u003e, otherwise in the beginning. The \u003carg_proto\u003e lines of\n# \u003carg_pjl /\u003e options are PJL commands which are sent to the printer\n# before the output of the driver's command line is sent. Because this\n# only works reliably when the driver output does not have its own PJL\n# command header, these options are ignored when the driver's XML file\n# is marked with a \u003cnopjl /\u003e tag in its \u003cexecution\u003e section. Drivers\n# which produce their own PJL and therefore are marked with \u003cnopjl /\u003e\n# are for example \"hpijs\" and \"hl1250\". There is also the\n# \u003carg_composite /\u003e execution style for composite options, see the\n# \"Composite Options\" section below. The user's value gets put into\n# the \u003carg_proto\u003e's %s location. \n\n# The \u003carg_group\u003e...\u003c/arg_group\u003e tags put the option into the PPD\n# option group named here. In many PPD-based GUIs (\"kprinter\", \"xpp\",\n# OpenOffice.org, ...) every group is shown as a tab or a tree branch\n# containing the member options of this group. You can also specify\n# subgroups. Then you have to use a \"group path\" similar to directory\n# paths, with the group and subgroup names separated by slashes\n# (\u003carg_group\u003eGeneral/Paper\u003c/arg_group\u003e is the \"Paper\" subgroup in the\n# \"General\" group). Subgroups are not recommended as there is no GUI\n# supporting them. If an option is member of a composite option (See\n# \"Composite Options\" section below), the \u003carg_group\u003e...\u003c/arg_group\u003e\n# tags will be ignored.\n\n  \u003carg_execution\u003e\n   \u003carg_group\u003eGeneral\u003c/arg_group\u003e\n   \u003carg_order\u003e100\u003c/arg_order\u003e\n   \u003carg_section\u003eDocumentSetup\u003c/arg_section\u003e\n   \u003carg_spot\u003eZ\u003c/arg_spot\u003e\n   \u003carg_postscript /\u003e\n   \u003carg_proto\u003e\u0026lt;\u0026lt;/PageSize[%s]/ImagingBBox null\u0026gt;\u0026gt;setpagedevice\u003c/arg_proto\u003e\n  \u003c/arg_execution\u003e\n\n# The constraints define what printer/driver combinations this option\n# applies to.  The *most specific* constraint rules the day; it's\n# \"sense\" says whether or not the option is \"in\".  The winning\n# constraint also provides the default value used when this option\n# applies to that printer and driver.\n\n# Constraint elements are: driver, make, model.  The driver is the\n# driver name, or not present to apply to any driver.  The make is the\n# printer make, or not present to apply to any printer make.  The\n# model is the driver model, or not present to apply to any printer.\n# Instead of make/model, you can also specify \u003cprinter\u003eid\u003c/printer\u003e.\n\n# IMPORTANT: The make and model must match the one in the printer xml\n# definition, and everywhere else in the other options. One needs to\n# write a utility to change printer names sensibly.\n\n# It is illegal to have a model with no make.\n\n# It is illegal to have none of make/model/driver.\n\n# It is illegal to have *no* constraints, or at least such options are\n# never used.\n\n# For enum options, the defval is the id of the enum_val that is the\n# default.  For other option types, it is the actual default value\n# (ie, a number, or 1 or 0 for boolean, etc).\n\n  \u003cconstraints\u003e\n     \u003cconstraint sense=\"true\"\u003e\n      \u003cdriver\u003esj48\u003c/driver\u003e\n      \u003carg_defval\u003eev/1\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n     \u003cconstraint sense=\"true\"\u003e\n      \u003cdriver\u003er4081\u003c/driver\u003e\n      \u003carg_defval\u003eev/1\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n# A gajillion constraints deleted\n  \u003c/constraints\u003e\n  \u003cenum_vals\u003e\n   \u003cenum_val id=\"ev/1\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003eUS Letter\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003eLetter\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in \n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n\n# If present, the driverval is what gets substituted in for the %s in\n# the option's prototype.  This way the user-visible stuff can be\n# anything.\n\n    \u003cev_driverval\u003e612 792\u003c/ev_driverval\u003e\n\n# This enum_val has no constraints.  It *is* OK for enum_vals to\n# have no constraints; they are assumed to apply unless\n# constrained otherwise.\n\n   \u003c/enum_val\u003e\n   \u003cenum_val id=\"ev/115\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003eA3\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003eA3\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in \n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n    \u003cev_driverval\u003e842 1191\u003c/ev_driverval\u003e\n\n# Here are some example constraints for an enum_val.  The A3 size\n# paper doesn't fit on lots of printers, so there are various\n# constraints to make the right thing happen.\n\n    \u003cconstraints\u003e\n     \u003cconstraint sense=\"true\"\u003e\n      \u003cdriver\u003eml85p\u003c/driver\u003e\n      \u003carg_defval\u003ena\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n     \u003cconstraint sense=\"true\"\u003e\n      \u003cmake\u003eHP\u003c/make\u003e\n      \u003cmodel\u003eDeskJet 1000C\u003c/model\u003e\n      \u003cdriver\u003epnm2ppa\u003c/driver\u003e\n      \u003carg_defval\u003ena\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n     \u003cconstraint sense=\"false\"\u003e\n      \u003cmake\u003eHP\u003c/make\u003e\n      \u003cmodel\u003eDeskJet 820C\u003c/model\u003e\n      \u003cdriver\u003epnm2ppa\u003c/driver\u003e\n      \u003carg_defval\u003ena\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n\n     # lots more...\n\n    \u003c/constraints\u003e\n   \u003c/enum_val\u003e\n  \u003c/enum_vals\u003e\n\u003c/option\u003e\n\n# To allow custom page sizes to be used one has add a choice with the\n# \"\u003cev_shortname\u003e\" being \"Custom\" to the \"PageSize\" option (example\n# below). This choice will be treated as the custom page size. When\n# the user selects this choice, he has to provide the width and the\n# height of the page in addition. These values are converted into\n# PostScript points (1/72 inches) and inserted into placeholders in\n# the \"\u003cev_driverval\u003e\" of this choice. The \"\u003cev_driverval\u003e\" should\n# contain a placeholder \"%0\" for the page width and \"%1\" for the page\n# height. Alternatively the \"\u003cev_driverval\u003e\" can contain two zeros\n# (\"0\") from which the first will be replaced by the page width and\n# the second by the page height. Then one gets Adobe-compliant entries\n# for the custom page size in the PPD files and one can set a custom\n# page size with the following commands:\n\n# CUPS: lpr -P huge -o PageSize=Custom.500x750cm bigposter.ps\n# LPRng: lpr -P huge -Z PageSize=Custom.500x750cm bigposter.ps\n# GNUlpr: lpr -P huge -o PageSize=Custom.500x750cm bigposter.ps\n# LPD: lpr -P huge -JPageSize=Custom.500x750cm bigposter.ps\n# PPR (RIP): ppr -P huge -F \"*PageSize Custom\" --ripopts 500x750cm\n#          bigposter.ps\n# PPR (Int.): ppr -P huge -F \"*PageSize Custom\" -i 500x750cm bigposter.ps\n# PDQ: pdq -P huge -oPageSize_Custom -aPageWidth=500\n#          -aPageHeight=750 -oPageSizeUnit_cm bigposter.ps\n# No spooler: foomatic-rip -P huge -o PageSize=Custom.500x750cm\n#\t   bigposter.ps\n\n# Here is an example for a custom page size setting:\n\n#   \u003cenum_val id=\"ev/PageSize-Custom\"\u003e\n#    \u003cev_longname\u003e\n#     \u003cen\u003eCustom size\u003c/en\u003e\n#    \u003c/ev_longname\u003e\n#    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n#         it should be treated as documentation for the user. --\u003e\n#    \u003cev_shortname\u003e\n#     \u003cen\u003eCustom\u003c/en\u003e\n#     \u003c!-- Until someone tells me how to learn the user locale in \n#          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n#    \u003c/ev_shortname\u003e\n#    \u003cev_driverval\u003e%0 %1\u003c/ev_driverval\u003e\n#   \u003c/enum_val\u003e\n\n# The entry\n\n#    \u003cev_driverval\u003e0 0\u003c/ev_driverval\u003e\n\n# would have the same effect as the \u003cev_driverval\u003e of the example.\n\n# For numerical (int, float) and bool options there is no \u003cenum_vals\u003e\n# section. Instead of this section numerical options have tags to\n# specify minimum and maximum value:\n\n#  \u003carg_max\u003e10.0\u003c/arg_max\u003e\n#  \u003carg_min\u003e0.0\u003c/arg_min\u003e\n\n# For the %s in the \u003carg_proto\u003e a number, either the user's choice\n# when he has specified this option or the default value is\n# inserted. Only numbers between the minimum and the maximum and in\n# case of int options only integer numbers are allowed.\n\n# Bool options can be set or not be set. There \u003carg_proto\u003e will be\n# inserted if they are set, nothing if they are not set. A %s in the\n# \u003carg_proto\u003e is not allowed, there is nothing to insert for it. As\n# \u003carg_defval\u003e in the option's constraints one can use 0 for not\n# setting the option by default or 1 for setting it by default.\n\n# Bool options need the specification of a name for the case when they\n# are not set. This will be used by GUIs and in PPD files:\n\n#  \u003carg_shortname_false\u003e\n#    \u003cen\u003eCorrectBlack\u003c/en\u003e\u003c!-- Backends only know \u003cen\u003e shortnames! --\u003e\n#  \u003c/arg_shortname_false\u003e\n\n# This name should not contain spaces, \":\", or \"/\".\n\n# See below for string, password, and composite options.\n\n\nComposite Options\n-----------------\n\nThis is an option type to make it easier for users to choose the best\nsettings for a certain printing task, even if the driver has very many\noptions. The idea is to have an enumerated choice option which does\nnot directly modify something in the driver's command line but sets\nseveral of the other options.\n\nOne example is the \"PrintoutMode\" option which will be made available\nfor all printer/driver combos which have at least one option regarding\nthe printout quality or document type. \n\nThe possible choices should be the same for every printer and driver,\nso that users (especially newbies) can bring their printers in the\nright mode by choosing one easy to understand item from a menu instead\nof having to switch several cryptic driver options. For now the\nchoices are the following:\n\n   Command line  GUI                Intention\n   -----------------------------------------------------------------------\n   Draft         Draft              Very fast, ink/toner-saving printout\n   Normal        Normal             Quick standard quality printout\n   High          High Quality       High quality for plain paper\n   VeryHigh      Very High Quality  Highest quality for plain/inkjet paper\n   Photo         Photo              Highest quality for photo paper\n\nThese choices can also have one of the following modifiers:\n\n   Modifier      Intention\n   -----------------------------------------------------------------------\n   .Gray         Grayscale printing on a color printer\n   .Mono         Monochrome printing (no grayscales, black or white)\n\nExamples:\n\n   Command line   GUI                      Comment\n   ---------------------------------------------------------------------\n   High.Gray      High Quality Grayscale\n   Photo          Photo                    Color photos on color printer\n   VeryHigh.Mono  Very High Quality Monochrome  Really black text in\n                                           highest quality on inkjet\n                                           printer, not suitable for\n                                           halftone images.\n   Normal         Normal                   Standard color in 300/360 dpi\n                                           on normal paper, grayscale\n                                           on black-and-white printers\n\nNot all choices/combinations of basic choices and modifiers must be\npresent. Often modes are simply not available on certain\nprinter/driver combos, as \"Photo\" on most lasers. It is highly\nrecommended to have \"Normal\" available, though (and having this the\ndefault).\n\nThe GUI names can have additional remarks in parantheses, for example\nwhen manual intervention (other cartridge, photo paper) is needed.\n\nTo add such an option to the database, one only needs to add an option\nXML file like the one below into the db/source/opt directory of the\ndatabase. The file db/source/opt/pcl3-PrintoutMode.xml could look\nlike this:\n\n--------------------------------------------------------------------------\n\u003coption type=\"enum\" id=\"opt/pcl3-PrintoutMode\"\u003e\n  \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n       it should be treated as documentation for the user. --\u003e\n  \u003carg_longname\u003e\n   \u003cen\u003ePrintout Mode\u003c/en\u003e\n  \u003c/arg_longname\u003e\n  \u003carg_shortname\u003e\n   \u003cen\u003ePrintoutMode\u003c/en\u003e\u003c!-- backends only know \u003cen\u003e shortnames! --\u003e\n  \u003c/arg_shortname\u003e\n  \u003carg_execution\u003e\n   \u003carg_order\u003e10\u003c/arg_order\u003e\n   \u003carg_section\u003eAnySetup\u003c/arg_section\u003e\n   \u003carg_spot\u003eA\u003c/arg_spot\u003e\n   \u003carg_composite /\u003e\n   \u003c!-- \u003carg_proto\u003e\u003c/arg_proto\u003e --\u003e\n  \u003c/arg_execution\u003e\n  \u003cconstraints\u003e\n     \u003cconstraint sense=\"true\"\u003e\n      \u003cdriver\u003epcl3\u003c/driver\u003e\n      \u003carg_defval\u003eev/pcl3-PrintoutMode-Normal\u003c/arg_defval\u003e\n     \u003c/constraint\u003e\n  \u003c/constraints\u003e\n  \u003cenum_vals\u003e\n   \u003cenum_val id=\"ev/pcl3-PrintoutMode-Draft\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003eDraft\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003eDraft\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in\n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n    \u003cev_driverval\u003eMediaType=Plain Resolution=150 Quality=Draft IntensityRendering=Halftones Passes=1\u003c/ev_driverval\u003e\n   \u003c/enum_val\u003e\n   \u003cenum_val id=\"ev/pcl3-PrintoutMode-Normal\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003eNormal\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003eNormal\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in\n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n    \u003cev_driverval\u003eMediaType=Plain Resolution=300 Quality=Normal IntensityRendering=Halftones Passes=1\u003c/ev_driverval\u003e\n   \u003c/enum_val\u003e\n   \u003cenum_val id=\"ev/pcl3-PrintoutMode-High\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003eHigh\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003eHigh\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in\n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n    \u003cev_driverval\u003eMediaType=Plain Resolution=600 Quality=Presentation IntensityRendering=FloydSteinberg Passes=4\u003c/ev_driverval\u003e\n   \u003c/enum_val\u003e\n   \u003cenum_val id=\"ev/pcl3-PrintoutMode-Photo\"\u003e\n    \u003cev_longname\u003e\n     \u003cen\u003ePhoto (on photo paper)\u003c/en\u003e\n    \u003c/ev_longname\u003e\n    \u003c!-- A multilingual \u003ccomments\u003e block can appear here, too;\n         it should be treated as documentation for the user. --\u003e\n    \u003cev_shortname\u003e\n     \u003cen\u003ePhoto\u003c/en\u003e\n     \u003c!-- Until someone tells me how to learn the user locale in\n          backends, the shortname must be monolingual in \u003cen\u003e! --\u003e\n    \u003c/ev_shortname\u003e\n    \u003cev_driverval\u003eMediaType=Premium Resolution=600 Quality=Presentation IntensityRendering=FloydSteinberg Passes=4\u003c/ev_driverval\u003e\n   \u003c/enum_val\u003e\n  \u003c/enum_vals\u003e\n\u003c/option\u003e\n--------------------------------------------------------------------------\n\nThe shown option is only an example, it is neither in the BZR\nrepository nore will it work with all printers which use the \"pcl3\"\ndriver. You can paste it into a file (make the \u003cev_driverval\u003es being\none line, the items separated by spaces) and copy it to db/source/opt/\nto try it out.\n\nThe \"\u003carg_composite /\u003e\" tag for the execution style specifies it as a\ncomposite option. The \u003carg_spot\u003e and \u003carg_proto\u003e are meaningless in a\ncomposite option and the \"\u003cev_driverval\u003e\"s contain a space-separated\nlist of all settings of which the pre-made configuration represented\nby this choice consists. Every choice of the composite option must set\nEXACTLY THE SAME individual options. In no choice it is allowed to\nleave out one of them. These individual options are the member options\nof the composite option. Not all options of a driver/printer combo\nneed to be member options of the composite option. It is not allowed\nto have one option being member of more than one composite option. The\ncomposite option must be an enumerated choice option, the member\noptions must be enumerated choice or boolean options. Member options\ncan even be composite options, so composite options can be nested.\n\nIt is enough to add a composite option as shown. The PPD generator\n(getppd() in lib/Foomatic/DB.pm, package \"foomatic-db-engine\") will\ntake care of the rest. It will\n\n   - Order all member options into a group (PPD group, see \"Option\n     Grouping\" below) named after the composite option.\n\n   - Add to every member option the choice \"Controlled by '\u003cname of\n     the composite option\u003e'\" and make this choice the default. If this\n     is chosen, the composite option will set the value for this\n     member, depending on what value is chosen for the composite\n     option. If the user chooses something else than \"Controlled by\n     '\u003cname of the composite option\u003e'\" the member option does not obey\n     the setting given by the composite option. So the advanced user\n     can also set the member options individually.\n\n   - If necessary the \u003carg_order\u003e and \u003carg_section\u003e of the composite\n     option is replaced by other values in the PPD file, so that the\n     composite option will be stuffed into the PostScr","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenprinting%2Ffoomatic-db-engine-4","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopenprinting%2Ffoomatic-db-engine-4","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopenprinting%2Ffoomatic-db-engine-4/lists"}