SDB:Information for Printer Manufacturers Regarding Linux Support

Situation

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

This article is for CUPS up to version 2.x under Linux with the traditional filtering system and backends there.

The nowadays driverless printing workflow is rather different.

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:

Which printer models work how well with existing free Linux drivers.
Which printer models work how well with existing proprietary Linux drivers.
Which printer models do not work with Linux.
Which printer models are software-compatible with each other (printer language).

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 SDB:Purchasing a Printer 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://hplipopensource.com/hplip-web/tech_docs/device_classes.html).

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 basic print system CUPS is secondary in importance. 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 OpenPrinting/LinuxPrinting.org: http://www.linux-foundation.org/en/OpenPrinting. Check http://www.linux-foundation.org/en/OpenPrinting/Database/HowToContribute 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://hplipopensource.com/hplip-web/supported_devices/index.html

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. It cannot work if diverse print systems would have to run concurrently on the same host when a print server for various printers should be set up.

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

have an open source code,
be subject to a sufficiently free license (e.g., GPL, BSD) that permits modification of the source code, distribution, and redistribution (see "Debian Free Software Guidelines (DFSG)" at http://www.debian.org/social_contract.html#guidelines),
have a platform-independent source code.

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.

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

in all products containing a print system,
on all hardware platforms for which these products are available,
for new versions of the products containing a print system

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 Imaging and Printing (HPLIP)" project at http://hplipopensource.com

The actual Linux driver must be distinguished from any additional software (e.g., 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 SDB: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?

As we always compile the Linux drivers for the various hardware platforms from the source code, problems may be encountered due to the fact that the source code is not fully platform-independent. In this case, we must be able to modify the source code so that it can be compiled for the various hardware platforms.
In our tests, we may detect bugs in the Linux driver or in PPD files. In this case, we must be able to modify the source code in order to avoid or eliminate these bugs.
For time reasons, we must be able to perform such modifications immediately without having to obtain a permission.

Feedback about problems and possible solutions is sent to the authors of the Linux driver or the PPD file, thus enabling the long-term optimisation and fine-tuning of drivers and PPD files.

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

The distribution permission enables the integration of the Linux driver or PPD file in end-customer products through which the Linux driver or the PPD file is sold to end customers.
The redistribution permission enables the integration of the Linux driver or PPD file in OEM products through which the Linux driver or PPD file is sold by the "Original Equipment Manufacturer" to the end customers.

Overview and Index

In this context, "basic Linux support" means that normal printing works and the the output looks decent. However, the maximum resolution may not be supported, color tones may not be fully correct, or special functions (such as the selection of the paper tray or a special photo mode) may not be supported.

"Optimum Linux support" means that all printer functions the respective model is capable of are available in Linux.

If the Linux support is marked as "available", the support has already been implemented.

If the Linux support is marked as "possible", the support may not have been implemented yet, but can be achieved easily, e.g. by integrating a Linux driver that meets the above conditions.

PostScript Printers

Basic Linux support is always available.

For optimum Linux support, the following is needed:

A PPD file that is suitable for the respective PostScript printer.

PCL+JCL Printers

Basic Linux support is always available.

For optimum Linux support, the following is needed:

A PPD file that is suitable for the respective PCL+JCL printer.
Usually, a suitable script or program that performs an additional processing stage (see below).

Printers with Ghostscript Support

Basic Linux support is usually available and always possible.

For optimum Linux support, the following is needed:

A Ghostscript driver that support all printer functions of the respective model.
A PPD file that is suitable for the respective Ghostscript driver.
If necessary, a suitable script or program that performs an additional processing stage (see below).

Printers with CUPS "rasterto..." Support

Basic Linux support for the CUPS print system is usually available and always possible.

For optimum Linux support for the CUPS print system, the following is needed:

A "rasterto..." driver that supports all printer functions of the respective model.
A PPD file that is suitable for the "rasterto..." driver.

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.

Printers with "Postfilter" Support

Basic Linux support is possible, but may be difficult or impossible for normal users.

Optimum Linux support depends on the individual case and is often difficult or impossible for normal users.

Printers without Linux Support (GDI Printers)

For basic or optimum Linux support the printer manufacturer must provide a Linux driver. The following two options are viable:

A Ghostscript driver equips the printer with Ghostscript support. Ghostscript support provides independence from the print system, but requires an additional processing stage (see "Foomatic" below).

A CUPS "rasterto..." driver provides the printer with direct CUPS support. 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.

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.

In order to limit the structural complexity of the article, our focus is on the CUPS print system. There are limitations for other print systems like LPRng/lpdfilter. For CUPS, see http://www.cups.org/

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

If the print data are not PostScript, they will be converted to PostScript.
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.
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:

A PPD file that is suitable for the respective PostScript printer.

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.

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:

Each printer function is associated with a "main keyword".

Each option is associated with an "option keyword" and a "PostScript invocation value". An optional "translation string" serves the user-friendly display and can be localized.

* 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 work with it as well. For example, print dialog tools (e.g. KDE printing dialog or the Gnome printing dialog) 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.:

The printer functions do not match the printer:

Some defined printer functions are not available in the printer.
Some printer functions available in the printer are missing.

Incorrect options:

Some defined options are not supported by the printer.
Some options supported by the printer are missing.
Combinations of certain options that do not work together are not mutually excluded (e.g., duplex printing on transparencies), i.e. the PPD file lacks "constraints".
The default settings of the options conflict with existing "constraints" in the PPD file.

Incorrect PostScript code snippets:

Incorrect PostScript code snippets cause various errors in the printer's PostScript interpreter.

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

If the print data are not PostScript, they will be converted to PostScript.
If necessary, suitable JCL control commands that the printer needs for activating special printer functions such as the selection of the paper tray, duplex mode, or toner saving mode are added to 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.
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 the section "Printers with Ghostscript Support".
3. Rejoining of the PCL data and JCL control commands.
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:

A PPD file that is suitable for the respective PCL+JCL printer.
A suitable script or program that performs the above-mentioned additional processing stage.

Foomatic PPD files for a large number of PCL printers are available at OpenPrinting/LinuxPrinting.org: http://www.linux-foundation.org/en/OpenPrinting. 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 SDB: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:

Many printer models have Ghostscript support for (almost) all of their options.

Many printer models only have basic support, i.e. normal printing works and looks good, but high-resolution graphics printing may not be possible, color tones may not be printed correctly, or special functions (e.g., paper tray selection or a special photo mode) may not be supported. For example all PCL printers have at least basic Ghostscript support.

Some printer models are only supported rudimentarily, i.e. normal printing works, but does not look good or color printing is unacceptable or impossible.

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 in the section "PCL+JCL Printers".

Basic Processing Stages

If the print data are not PostScript, they will be converted to PostScript.
A Ghostscript driver that is suitable for the respective printer model is used to convert the PostScript data to the printer language.
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

If the print data are not PostScript, they will be converted to PostScript.
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.
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.
The printer-specific data are sent to the printer.

Optimum Linux Support

For optimum Linux support, the following is needed:

A Ghostscript driver that supports all printer functions of the respective model.
A suitable PPD file.
A suitable script or program that performs the above-mentioned additional processing stage.

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?

Formerly, Ghostscript drivers used to be compiled directly into Ghostscript. The disadvantage of this approach is that new Ghostscript drivers must be added to the Ghostscript sources in the form of patches and Ghostscript must be recompiled. Today, new Ghostscript drivers should be prepared as separate IJS modules which have a separate source code and can be compiled independently. Ghostscript provides the IJS interface needed for this purpose; see "IJS - Inkjet and other raster devices" at http://www.cs.wisc.edu/~ghost/doc/cvs/Devices.htm#IJS and "the website for IJS" at http://www.linuxprinting.org/ijs/. The HPIJS driver from HP is an example for how a Linux driver can be prepared by a printer manufacturer as an IJS module.

For the following reasons, a Ghostscript driver (actually every Linux printer driver) must work even without bidirectional communication with the printer:

The printer may be connected via the network and a print server box; usually printer server boxes do not enable bidirectional communication.
It must be possible to print the printer-specific data to a file and to send this file directly to the printer at any time later on.

Actually, a Ghostscript driver is only a simple filter that converts Ghostscript raster graphics data to printer-specific raster graphics data. Ghostscript processes the data in two separate stages:

The PostScript data are rasterized, i.e. the image (in this context even text is an image) described in the PostScript language is represented as a fine raster of individual pixels. At this stage, Ghostscript operates without the respective Ghostscript driver.
Then the respective Ghostscript driver is used to convert the rasterized image to the desired printer language in the data format in which the printer can print raster graphics data.

Therefore, the source code for a Ghostscript driver can be platform-independent without any special tricks.

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 Gutenprint Ghostscript driver; see http://gimp-print.sourceforge.net/). Certain printer models feature internal dithering (e.g., the models compatible with the 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 "rastertogutenprint" from Gutenprint (http://gimp-print.sourceforge.net/).

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

Many printer models have support for (almost) all of their options.

Many printer models only have basic support, i.e. normal printing works and looks good, but high-resolution graphics printing may not be possible, color tones may not be printed correctly, or special functions (e.g., paper tray selection or a special photo mode) may not be supported. For example all PCL printers have at least basic "rastertogutenprint" support.

Some printer models are only supported rudimentarily, i.e. normal printing works, but does not look good or color printing is unacceptable or impossible.

Processing Stages

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.
A CUPS "rasterto..." printer driver converts the CUPS raster data and the parameters to the printer-specific data.
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.

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?

Basic information on CUPS "rasterto..." drivers and PPD files is available in the CUPS documentation at http://www.cups.org/documentation.php

A "rasterto..." driver must work even without bidirectional communication with the printer (see above section on Ghostscript drivers).

Actually, a "rasterto..." driver is only a simple filter that converts CUPS raster graphics data to printer-specific raster graphics data. Therefore, the source code for a "rasterto..." driver can be platform-independent without any special tricks.

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.

If the print data are not PostScript, they will be converted to PostScript.
A Ghostscript driver that is suitable for the respective "Postfilter" is used to convert the PostScript data to raster data.
A "Postfilter" that is suitable for the respective printer converts these raster data to printer-specific data.
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".

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

Optimum Linux Support

For optimum Linux support, the following is needed:

A "Postfilter" that supports all printer functions of the respective model.
A suitable PPD file.
A suitable script or program that runs the Ghostscript driver and the "Postfilter" with suitable parameters.

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":

If the print data are not PostScript, they will be converted to PostScript.
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.
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.
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 SDB:GDI Printers.

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

A free Open Source Linux driver.
A suitable PPD file.
If necessary, a suitable script or program that performs an additional processing stage as described above.

Only the following two approaches are viable:

Implementation of an IJS driver module that provides the printer with print-system-independent Ghostscript support; see the section "Printers with Ghostscript Support".

A CUPS "rasterto..." driver provides the printer with direct CUPS support; see the section "Printers with CUPS "rasterto..." Support". 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.

Further Information

Portal:Printing