Information for Printer Manufacturers Regarding Linux Support

This document is a preview. The actual document will be soon public available in our support database http://portal.suse.com/sdb/en/index.html.

Situation

You are a printer manufacturer or offer software that needs special printer support and want to achieve basic or optimum Linux support.

General Information

This article addresses technicians as well as non-technicians.
However, the issues involved cannot be described or understood without a technical basis. Without being technically precise, the multiplicity of this subject would lead to confusion.

This article is split into a general part and a technical part:
The general part comes first and ends with an Overview and Index which itemizes the individual situations. These items are covered in the technical part. Technical details are covered in subsections marked accordingly. As the technical details include background information on licensing issues, they may also be interesting for non-technicians.

Public Information

Most important is to have information public available: It is important which version of which Linux driver supports the respective printer model how well.

Information on the compatibility is essential in order to categorize the growing number of printer models and model variants. The most suitable approach is a classification in compatibility-classes, each of which contains the printer models that are software-compatible, i.e. which support the same printer language and work with the same Linux drivers and Linux driver settings (see the article "Purchase of Printers and Compatibility"). Normally, printer drivers are not different for every single model, but only for every compatibility-class. For instance, the HPIJS driver from HP is based on this policy (see http://hpinkjet.sourceforge.net/printmodedescr.php). Compatibility-classes are also evident from the "pcl-xxx" classes and some of the "bjc-xxx" classes in the list of Gimp-Print drivers (see http://gimp-print.sourceforge.net/p_Supported_Printers.php3).

This is the minimum information every printer manufacturer should make available publicly in order to enable customers to choose a suitable printer model. After all, the most important precondition for hassle-free printing is the selection of a suitable printer model.

The selection of the print system (CUPS or LPRng/lpdfilter) is secondary in importance, as both work smoothly. Problems with the print system can usually be resolved by modifying the configuration. Though it may not be possible to satisfy any wish but an adequate solution is available for virtually all problems. However, most problems caused by an unsuitable printer cannot be solved by simply modifying the configuration of the print system.

Visit the most comprehensive Linux printer database at http://www.linuxprinting.org/. Check http://www.linuxprinting.org/contribute.html for a detailed description of the needed information.

Of course, the same information can also be published at web pages of the printer manufacturer, such as http://hpinkjet.sourceforge.net/productssupported.php

It is not necessary but very useful to have information about the exact identification strings of the particular model when it is polled via parallel port (IEEE-1284), via USB or via SNMP. Such model identification strings make it possible to autodetect the model and to configure it automatically if a driver is available.

Conditions

The Linux support of printers should not be realized by implementing an entirely new custom print system. The host cannot be used as a print server for various printers if diverse print systems are used on one machine.

No matter how the Linux support is implemented, it must be integrated smoothly in existing structures, i.e. it must be compatible with the processing stages of the existing print systems. The main aim of this article is to provide the basic information needed for this purpose.

This does not mean that you cannot develop a new custom print system in addition to the possibilities outlined below; rather, it means that the Linux support of printers must not depend on such a print system.

Linux drivers and PPD files for printer must

Thus, we will be able to integrate it in our products, as the standard software for our products is compiled separately for the various hardware platforms from the source code.

Though this does not mean that we cannot integrate any proprietary software in our products, it does mean that we cannot do this regularly but only if it is interesting for us. As there are hundreds of printer models that work very efficiently with free Open Source Linux drivers, it is rather unlikely that proprietary Linux drivers will be interesting for us.

Normally, proprietary Linux drivers are not interesting for users either. Since the cost for a functional new printer is relatively low, the effort and cost spent for a proprietary Linux driver may seem a waste of time and money. What is more, using a proper printer will solve the driver problem once and for all, as it will eliminate the need for installing and configuring proprietary driver software and obtaining driver updates required for new developments in the print system (for example, see the article "Problems with Lexmark Drivers under SuSE Linux 8.1").

Linux drivers from printer manufacturers that meet these conditions are fit for standard integration in our products.

The advantage for the printer manufacturer is that he will receive comprehensive Linux support for his devices

without any extra expenses for the printer manufacturer.

The HPIJS driver from HP is a fine example of how a Linux driver can be designed. Visit the "hp linux inkjet project" at http://hpinkjet.sourceforge.net/.

The actual Linux driver must be distinguished from any additional software (remote printer administration tools, etc.). Only the actual Linux driver must meet the above requirements.

Summary:
We do not want to promote any Linux drivers for printers that cannot be integrated smoothly in existing print systems. See section "Notes" in the article "GDI Printers".

It is a different case when a manufacturer already has proprietary software (e.g. a proprietary custom print system) and is looking for an operating system to provide a complete server solution. This can be achieved by using an OEM version of a SUSE LINUX server product.

Details

Why must modifications of the source code be permitted for Linux drivers and PPD files? Feedback about problems and possible solutions is sent to the authors of the Linux driver or the PPD file, thus enabling the long-term fine-tuning of drivers and PPD files.

Why must distribution and redistribution be permitted for Linux drivers and PPD files?

Overview and Index

PostScript Printers PCL+JCL Printers Printers with Ghostscript Support Printers with CUPS "rasterto..." Support Printers with "Postfilter" Support Printers without Linux Support (GDI Printers)

General Information on the Technical Part

With respect to Linux support, the technical part progresses from the easiest case (PostScript printers) to more difficult cases. Knowledge of the easier cases is necessary for the more difficult cases.

Every case starts with a definition of the printer type and a basic explanation of relevant terms.

This is followed by a basic outline of the processing stages that are needed to send the correct data to the printer. This is a prerequisite for understanding what the respective Linux support must be like, what is essential for basic Linux support, and what is sufficient for optimum Linux support.

The processing stages can differ depending on the print system (CUPS or LPRng/lpdfilter). Accordingly, the level of Linux support may also vary.

In order to limit the structural complexity of the article, our main focus is on the CUPS print system. Limitations of the Linux support for LPRng/lpdfilter are indicated when necessary. For CUPS, see http://www.cups.org/. For LPRng, see http://www.lprng.com/.

PostScript Printers

The term "PostScript printer" refers to a printer that supports "PostScript level 2" or "PostScript level 3".

PostScript was developed by Adobe and is the standard printer language in Linux.

Processing Stages

  1. If the print data are not PostScript, they will be converted to PostScript.
  2. If necessary, suitable control commands that the printer needs for activating special printer functions such as the selection of the tray, duplex mode, or toner saving mode are inserted in the PostScript data. All printer functions and the associated control commands of a PostScript printer are stored in a printer-specific PPD file.
  3. The PostScript data plus the control commands are sent to the printer.

Basic Linux Support

As a PostScript printer can print the PostScript data directly, basic Linux support is always available for PostScript level 2 or level 3 printers, regardless of the print system.

Basic Linux support for PostScript level 1 printers is always possible with an additional processing stage that generates PostScript level 1.

Optimum Linux Support

For optimum Linux support, the following is needed: For PostScript printers, PPD files are already available, as all manufacturers enclose suitable PPD files with the printers.

However, printer manufacturers often provide the PPD files in an awkward format for other operating systems (e.g., self-extracting EXE archives) - despite the fact that PPD files consist of plain ASCII text and are not so large that a compression would really be necessary.

Restrictive licenses for the PPD file can also prevent the utilization in Linux.

In this connection, see the article "Printer Configuration from SuSE Linux 8.2".

Technical Details

What is a PPD file and what is its purpose?

A PPD file contains the model-specific printer functions with its options and associated PostScript code snippets that must be sent to the PostScript printer in order to activate the selected function.

Pursuant to the "Adobe PostScript Printer Description File Format Specification, version 4.3", the structure of the entries for a printer function is as follows:

* main keyword option keyword / translation string : " PostScript invocation value "
*Resolution 300x300dpi/300 dots per inch: "<</HWResolution[300 300]>>setpagedevice"
*Resolution 600x600dpi/600 dots per inch: "<</HWResolution[600 600]>>setpagedevice"
The PostScript code snippets (PostScript invocation values) are the only element that could give rise to license concerns in connection with free PPD files. However, these code snippets merely serve the activation of printer functions and do not disclose how the print function is implemented in the printer. For instance, the above code snippets in no way reveal how the printer internally prints 300 DPI or 600 DPI.

The CUPS utility "cupstestppd", which is also available at http://www.cups.org/testppd.php, should be used to check every PPD file for compliance with the "Adobe PostScript Printer Description File Format Specification, version 4.3".

If the utility returns "FAIL", the errors in the PPD file are so serious that major problems can be expected if the PPD file is utilized. The problems indicated by "cupstestppd" should be eliminated.

If the utility returns "PASS" with "WARN" messages, the PPD file should be usable, but the problem spots indicated by "cupstestppd" do not comply with the above PPD specification.

PPD files that do not comply with the PPD specification can cause all kinds of errors. Even if CUPS is able to work with such a PPD file, this does not necessarily mean that other programs will with it. For example, print dialog tools (such as the KDE print dialog "kprinter", "xpp", "gtklp") or the print data processing in applications may have various kinds of problems with PPD files that do not comply with the PPD specification. Moreover, normal printing with the default settings in the PPD file may work smoothly, but other settings may cause problems.

If the utility returns "PASS" without any warnings, you can assume that the PPD file complies with the PPD specification, but nothing more. The PPD file may still contain major errors that prevent utilization, e.g.:

All of this can only be checked by the printer manufacturer who has the needed information about the internal details of the printer (especially the internal details of the PostScript interpreter in the printer).

PCL+JCL Printers

The term "PCL+JCL printer" refers to a printer that supports the printer language PCL and a job control language (JCL).

PCL (Printer Control Language) is a printer language from HP. Many printer models of other manufacturers also support PCL. Similar to PostScript, PCL also has several levels: PCL3, PCL4, PCL5, PCL5e, PCL6, PCLXL.

PJL (Printer Job Language) is a job control language from HP. Many printer manufacturers have their own job control languages.

PCL is the page description language (PDL) that tells the printer how the printout should look like. For example, it may tell the printer to print the word "Hello".

In contrast, the job control language tells the printer how the printout is to be made, e.g. from which tray the paper is to be taken and whether to activate the duplex mode or the toner saving mode.

Processing Stages

  1. If the print data are not PostScript, they will be converted to PostScript.
  2. If necessary, suitable JCL control commands that the printer needs for activating special printer functions such as the selection of the tray, duplex mode, or toner saving mode are inserted in the PostScript data. For printers that support a job control language, the printer functions and the needed JCL control commands can be stored in a printer-specific PPD file.
  3. The PostScript data plus the JCL control commands must be converted in an additional processing stage:
    1. Extraction of the JCL control commands.
    2. Conversion of the PostScript data to PCL. This conversion can be performed with Ghostscript. See section "Printers with Ghostscript Support".
    3. Rejoining of the PCL data and JCL control commands.
  4. The PCL data plus the JCL control commands are sent to the printer.

Basic Linux Support

For all above-mentioned PCL levels, suitable Ghostscript drivers are available for converting PostScript data to PCL. Thus, basic Linux support is always available for PCL printers, regardless of the print system.

Optimum Linux Support

For optimum Linux support, the following is needed: Foomatic PPD files for a large number of PCL printers are available at Linuxprinting.org: http://www.linuxprinting.org/. For certain PCL-Ghostscript drivers, the above-mentioned additional processing stage is performed by the Foomatic filter script "foomatic-rip" from Foomatic version 3.0.1. In the ideal case, Foomatic may provide optimum Linux support.

In many cases, however, the printer manufacturer will have to provide the suitable PPD file and the suitable additional processing stage. The latter is not necessary if a "foomatic-rip"-compatible PPD file is created.

Therefore, this should be done in line with Foomatic, as the basis for this already exists and Foomatic runs efficiently on hundreds of thousands of Linux installations. The best for all involved is the direct support and assistance of the printer manufacturers for the further development of Foomatic.

Technical Details

How can JCL printer functions be defined in a PPD file?

Here an example for the selection of the resolution via the job control language PJL:
*JCLResolution 300x300dpi/300 dots per inch: "@PJL SET RESOLUTION = 300"
*JCLResolution 600x600dpi/600 dots per inch: "@PJL SET RESOLUTION = 600"
The JCL control commands that are used instead of the PostScript code snippets are the only thing that could give rise to license issues in free PPD files. However, these JCL control commands merely serve the activation of printer functions and do not disclose how the print function is implemented in the printer. For instance, the JCL control commands in no way reveal how the printer internally prints 300 DPI or 600 DPI.

For the CUPS print system, the above-mentioned additional processing stage is defined as follows in the PPD file (example: Foomatic filter script "foomatic-rip"):
*cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
For detailed information on filter scripts see the article "Using Your Own Filters to Print with CUPS".

Printers with Ghostscript Support

Ghostscript (http://www.cs.wisc.edu/~ghost/) is a comprehensive program package for the conversion of PostScript data to other formats, especially to diverse printer languages. Ghostscript achieves this by means of a variety of Ghostscript drivers (e.g., see http://www.cs.wisc.edu/~ghost/doc/printer.htm).

A printer has Ghostscript support if a Ghostscript driver is available for its printer language.

The level of support for a specific printer model depends on the respective Ghostscript driver:

In Ghostscript, the parameters (especially those of the respective Ghostscript driver) needed for the print output are set by means of various command-line options.

The following information assumes that the printer does not support any job control language. A printer with Ghostscript support and which supports additionally a job control language can be handled as described under "PCL+JCL Printers".

Basic Processing Stages

  1. If the print data are not PostScript, they will be converted to PostScript.
  2. A Ghostscript driver that is suitable for the respective printer model is used to convert the PostScript data to the printer language.
  3. The printer-specific data are sent to the printer.

Basic Linux Support

For a printer with basic Ghostscript support, basic Linux support is always possible, regardless of the print system.

For a printer without Ghostscript support, a suitable Ghostscript driver must be developed in order to achieve print-system-independent Linux support. A special alternative for CUPS is described in the section "Printers with CUPS 'rasterto...' Support".

Processing Stages for Optimum Linux Support

  1. If the print data are not PostScript, they will be converted to PostScript.
  2. If necessary, pseudo-control-commands are added to the PostScript data and converted into the actual Ghostscript parameters in the next processing stage. This especially applies to parameters that the respective Ghostscript driver needs for activating special printer functions. The printer functions and the needed pseudo-control-commands can be stored in a printer-specific PPD file.
  3. The PostScript data plus the pseudo-control-commands must be converted as follows in an additional processing stage:
    1. The pseudo-control-commands are used to generate a Ghostscript command line containing suitable Ghostscript parameters.
    2. By executing the Ghostscript command line, the PostScript data are converted to the respective printer-specific data.
  4. The printer-specific data are sent to the printer.

Optimum Linux Support

For optimum Linux support, the following is needed:

Foomatic PPD files for a large number of printers are available at Linuxprinting.org: http://www.linuxprinting.org/. The above-mentioned additional processing stage is performed by the Foomatic filter script "foomatic-rip" from Foomatic version 3.0.0. In the ideal case, Foomatic may provide optimum Linux support.

Very often, optimum Linux support can be achieved by simply fine-tuning the Ghostscript parameters in the Foomatic PPD files (e.g., in order to obtain optimum color tones).

In many cases, however, the printer manufacturer will have to provide the Ghostscript driver, the suitable PPD file, and the suitable script or program for the additional processing stage. The latter is not necessary if a "foomatic-rip"-compatible PPD file is created.

Therefore, this should be done in line with existing Ghostscript drivers and Foomatic, as the basis for this already exists. The best for all involved is the direct support and assistance of the printer manufacturers for the further development of Ghostscript drivers and Foomatic.

A special alternative for CUPS is described in the section "Printers with CUPS 'rasterto...' Support".

Technical Details

How can Ghostscript parameters be defined in a PPD file by means of pseudo-control-commands?

For instance, for PCL5e printers that are compatible with the HP LaserJet 4, the Ghostscript driver "ljet4" can be addressed with the command-line parameter "-sDEVICE=ljet4". The resolutions 300x300 DPI and 600x600 DPI can be specified as command-line parameters: "-r300x300" or "-r600x600". Thus, a Ghostscript command such as "gs -sDEVICE=ljet4 -r300x300 ..." can be used to generate PCL5e printer data with a resolution of 300 DPI.

The following example shows the selection of these Ghostscript parameters by means of pseudo-control-commands for the Foomatic filter script "foomatic-rip" in a Foomatic PPD file: 

*cupsFilter: "application/vnd.cups-postscript 0 foomatic-rip"
...
*FoomaticRIPCommandLine: "gs ... -sDEVICE=ljet4 %B ..."
...
*FoomaticRIPOption Resolution: enum CmdLine B
*DefaultResolution: 300x300dpi
*Resolution 300x300dpi/300 DPI: "%% FoomaticRIPOptionSetting: Resolution=300x300dpi"
*FoomaticRIPOptionSetting Resolution=300x300dpi: " -r300x300 "
*Resolution 600x600dpi/600 DPI: "%% FoomaticRIPOptionSetting: Resolution=600x600dpi"
*FoomaticRIPOptionSetting Resolution=600x600dpi: " -r600x600 "
"FoomaticRIPOption ... B" causes the placeholder "%B" in the "FoomaticRIPCommandLine" to be replaced by the Ghostscript parameter.

The indirect reference to the actual Ghostscript parameters with "Resolution=300x300dpi" and "Resolution=600x600dpi" is used for security reasons, as a direct specification of the Ghostscript parameters, e.g. in the form 

*Resolution 300x300dpi/300 DPI: "%% FoomaticRIPOptionSetting: -r300x300 "
would generate the following line in the PostScript data stream: 
%% FoomaticRIPOptionSetting: -r300x300
In case the filter script gets the Ghostscript parameter from here, a malicious user could change this line to 
%% FoomaticRIPOptionSetting: $( rm -rf /* )
resulting in the Ghostscript command 
gs ... -sDEVICE=ljet4 $( rm -rf /* ) ...
which would delete all files that the user under whose identity the filter script runs is permitted to delete.

In contrast, the indirect reference generates the line 

%% FoomaticRIPOptionSetting: Resolution=300x300dpi
and the filter script gets the Ghostscript parameter from the respective "*FoomaticRIPOptionSetting" line in the PPD file, provided it can find a suitable line. If no suitable line is found, the default setting is used. The PPD file itself is secure, as it can only be modified by the system administrator.

This example shows why custom developments should be made in line with existing Ghostscript drivers and Foomatic, as these utilities are based on the experience of many developers and the feedback from hundreds of thousands of Linux installations.

What must be kept in mind when developing a new Ghostscript driver?

License concerns in connection with Open Source Ghostscript drivers:

A printer manufacturer could be afraid of having to reveal all internal details of his models by means of an Open Source Ghostscript driver. However, this fear is unfounded, as a Ghostscript driver merely serves the conversion of Ghostscript raster graphics data to printer-specific raster graphics data. Thus, the data format is the only detail that needs to be disclosed in an Open Source Ghostscript driver in order to enable the transmission of raster graphics data to the printer. Normally, this does not reveal how the printer actually prints the raster graphics data.

For basic Linux support, the dithering (digital halftoning) algorithms do not need to be disclosed, as basic Ghostscript dithering can take place in the first stage. However, for optimum printing results the dithering may need to be customized for the respective printer model in the Ghostscript driver (such as in the Gimp-Print Ghostscript driver; see http://gimp-print.sourceforge.net/). Certain printer models feature internal dithering (e.g., the models compatible with HP DeskJet 990C), so all the Ghostscript driver needs to do is to activate the printer's internal dithering.

Printers with CUPS "rasterto..." Support

This section only covers the direct CUPS support of non-PostScript printers. PostScript printers are supported by CUPS as described above.

A printer has CUPS "rasterto..." support if a "rasterto..." printer driver is available for its printer language. Currently, the most important "rasterto..." driver is "rastertoprinter" from Gimp-Print (http://gimp-print.sourceforge.net/).

The level of support for a specific printer model depends on the respective "rasterto..." driver. For "rastertoprinter", see the list of "Gimp-Print Supported_Printers" at http://gimp-print.sourceforge.net/p_Supported_Printers.php3.

Processing Stages

  1. Conversion of the print data to CUPS raster data. If necessary, suitable parameters enabling the "rasterto..." printer driver to activate special printer functions are added. The printer functions are stored in a PPD file associated with the "rasterto..." printer driver and the respective printer.
  2. A CUPS "rasterto..." printer driver converts the CUPS raster data and the parameters to the printer-specific data.
  3. The printer-specific data are sent to the printer.

Basic Linux Support

For printers with basic CUPS "rasterto..." support, basic Linux support is always possible for the CUPS print system.

For printers without basic CUPS "rasterto..." support, a suitable "rasterto..." driver and a suitable PPD file must be developed in order to implement Linux support for the CUPS print system.

The LPRng/lpdfilter print system does not support "rasterto..." drivers directly. However, using the additional filter "foomatic-rip" from version 3.0.1, "rasterto..." drivers can also be used for the LPRng/lpdfilter print system. Moreover, a "rasterto..." driver with a platform-independent source code can also be used for the Mac OS X operating system, as Mac OS X uses the CUPS print system.

Optimum Linux Support

The information about basic Linux support also applies to optimum Linux support. Support level details depend on whether the "rasterto..." driver and the respective PPD file support all printer functions or not.

Technical Details

What must be kept in mind when developing a new CUPS "rasterto..." driver?

License concerns in connection with Open Source "rasterto..." drivers:

The license concerns in connection with Open Source "rasterto..." drivers correspond to the license concerns in connection with Open Source Ghostscript drivers as described above.

A printer manufacturer could be afraid of having to reveal all internal details of his models by means of an Open Source "rasterto..." driver. However, this fear is unfounded, as an Open Source "rasterto..." driver merely contains information on the data format in order to be able to transmit raster graphics data to the printer. The dithering algorithms do not need to be disclosed for basic Linux support. However, for optimum printing results the dithering may need to be customized for the respective printer model in the "rasterto..." driver (such as in the Gimp-Print "rastertoprinter" driver)."

Printers with "Postfilter" Support

Some printers currently only provide Linux support with a "Postfilter".

A "Postfilter" is a program that is used after an existing Ghostscript driver.

Ghostscript (see http://www.cs.wisc.edu/~ghost/) is a comprehensive program package for the conversion of PostScript data to other formats, especially to diverse raster graphics data formats. Ghostscript achieves this by means of a variety of Ghostscript drivers in particular for "Image file formats" (e.g., see http://www.cs.wisc.edu/~ghost/doc/cvs/Devices.htm#File_formats).

The "Postfilter" converts the raster data generated by the Ghostscript driver to printer-specific data, i.e. to a data format in which the printer can print raster graphics data.

Especially printers that do not support any regular standard printer language (GDI printers) sometimes have Linux support by means of a "Postfilter".

Only few of these printers offer more than basic Linux support.

Basic Processing Stages

The processing stages correspond to those for printers with Ghostscript support plus an additional processing stage in which the "Postfilter" is run.
  1. If the print data are not PostScript, they will be converted to PostScript.
  2. A Ghostscript driver that is suitable for the respective "Postfilter" is used to convert the PostScript data to raster data.
  3. A "Postfilter" that is suitable for the respective printer converts these raster data to printer-specific data.
  4. The printer-specific data are sent to the printer.

Basic Linux Support

For a printer with basic "Postfilter" support, basic Linux support is possible, regardless of the print system.

For a printer without basic "Postfilter" support, all that needs to be done is to develop a suitable "Postfilter" for an existing Ghostscript driver.

Today, Ghostscript drivers should be developed as IJS modules. Like "Postfilter", IJS modules have a separate source code and can be compiled independently. See "Technical Details" in the section "Printers with Ghostscript Support".

A special alternative for CUPS is described in the section "Printers with CUPS 'rasterto...' Support".

Optimum Linux Support

For optimum Linux support, the following is needed:

For optimum Linux support, the "Processing Stages for Optimum Linux Support" listed in the section "Printers with Ghostscript Support" must be expanded by an additional processing stage in which the "Postfilter" is run. Moreover, the suitable pseudo-control-commands must be passed to the Ghostscript driver and to the "Postfilter":

  1. If the print data are not PostScript, they will be converted to PostScript.
  2. If necessary, pseudo-control-commands are added to the PostScript data to be converted into the actual Ghostscript parameters and "Postfilter" parameters in the following processing stages. This especially applies to parameters that the respective Ghostscript driver and the "Postfilter" need for activating special printer functions. The printer functions and the needed pseudo-control-commands can be stored in a printer-specific PPD file.
  3. The PostScript data plus the pseudo-control-commands must be converted as follows in an additional processing stage:
    1. The pseudo-control-commands are used to generate a Ghostscript command line and a subsequent "Postfilter" command line containing suitable Ghostscript parameters and suitable "Postfilter" parameters.
    2. By executing the Ghostscript command line and the subsequent "Postfilter" command line, the PostScript data are converted to the respective printer-specific data.
  4. The printer-specific data are sent to the printer.
Foomatic PPD files for a number of printers with "Postfilter" support are available at Linuxprinting.org: http://www.linuxprinting.org/. The above-mentioned additional processing stage is performed by the Foomatic filter script "foomatic-rip" from Foomatic version 3.0.0. In the ideal case, Foomatic may provide near-to-optimum Linux support. It may be possible to achieve this by simply fine-tuning the Ghostscript and "Postfilter" parameters in the Foomatic PPD files.

Instead of developing an optimum "Postfilter", a Ghostscript driver should be developed as an IJS module (see above) in order to ensure a uniform interface (the IJS interface) to Ghostscript.

Printers without Linux Support (GDI Printers)

These are printers that cannot be addressed with a published standard printer language like PostScript or PCL, but only with a printer-specific proprietary printer language. These printers are usually referred to as "GDI printers", but as there is no common "GDI" printer language, the designation "printers that can only be addressed by means of a proprietary protocol" would be more correct. See the article "GDI Printers".

For basic or optimum Linux support, the printer manufacturer must provide the following:

  1. A free Open Source Linux driver.
  2. A suitable PPD file.
  3. If necessary, a suitable script or program that performs an additional processing stage as described above.
Only the following two approaches are viable:

Feedback appreciated:

Send Mail to jsmeix@suse.de (Please use the following subject: SDB-2003/11/jsmeix_print-info-for-manufacturers)