Details of Ghostscript output devices

Table of contents

For other information, see the Ghostscript overview. You may also be interested in how to build Ghostscript and install it, as well as the description of the driver interface.


Notes on measurements

Several different important kinds of measures appear throughout this document: inches, centimeters and millimeters, points, and bits per pixel.

Inches
1 inch equals 2.54 centimeters. The inch measure is sometimes represented by "in" or a quotation mark (") to the right of a measure, like 8.5in or 8.5". Dots per inch, "dpi", are the common measure of printing resolution for dot-matrix, laser, and ink-jet printers. U.S. "letter" paper is exactly 8.5in×11in, approximately 21.6cm×27.9cm. (See in the usage documentation all the paper sizes predefined in Ghostscript.)
Centimeters and millimeters
ISO standard paper sizes such as A4 and A3 are commonly represented in the SI units of centimeters and millimeters. Centimeters are abbreviated "cm", millimeters "mm". ISO A4 paper is quite close to 21.0×29.7 centimeters (approximately 8.3×11.7 inches).
Points
Points are a measure traditionally used in the printing trade and now in PostScript, which specifies exactly 72 points per inch (approximately 28.35 per centimeter). The paper sizes known to Ghostscript are defined in the initialization file gs_statd.ps in terms of points.
Bits per pixel
Commonly abbreviated "bpp".

MS Windows printers

MS Windows printers

This section was written by Russell Lang, the author of Ghostscript's MS Windows-specific printer driver, and updated by Pierre Arnaud, the current maintainer.

The mswinpr2 device uses MS Windows printer drivers, and thus should work with any printer with device-independent bitmap (DIB) raster capabilities. The printer resolution cannot be selected directly using PostScript commands from Ghostscript: use the printer setup in the Control Panel instead. It is however possible to specify a maximum resolution for the printed document (see below).

If no Windows printer name is specified in -sOutputFile, Ghostscript prompts for a Windows printer using the standard Print Setup dialog box. You must set the orientation to Portrait and the page size to that expected by Ghostscript; otherwise the image will be clipped. Ghostscript sets the physical device size to that of the Windows printer driver, but it does not update the PostScript clipping path.

If a Windows printer name is specified in -sOutputFile using the format "\\spool\printer_name", for instance

gs ... -sOutputFile="\\spool\Apple LaserWriter II NT"

then Ghostscript attempts to open the Windows printer without prompting (except, of course, if the printer is connected to FILE:). Ghostscript attempts to set the Windows printer page size and orientation to match that expected by Ghostscript, but doesn't always succeed. It uses this algorithm:

  1. If the requested page size matches one of the Windows standard page sizes +/- 2mm, request that standard size.
  2. Otherwise if the requested page size matches one of the Windows standard page sizes in landscape mode, ask for that standard size in landscape.
  3. Otherwise ask for the page size by specifying only its dimensions.
  4. Merge the requests above with the defaults. If the printer driver ignores the requested paper size, no error is generated: it will print on the wrong paper size.
  5. Open the Windows printer with the merged orientation and size.

The Ghostscript physical device size is updated to match the Windows printer physical device.

Supported command-line parameters

The mswinpr2 device supports a limited number of command-line parameters (e.g. it does not support setting the printer resolution). The recognized parameters are the following:

-sDEVICE=mswinpr2
Selects the MS Windows printer device. If Ghostscript was not compiled with this device as the default output device, you have to specify it on the command line.
-dNoCancel
Hides the progress dialog, which shows the percent of the document page already processed and also provides a cancel button. This option is useful if GS is intended to print pages in the background, without any user intervention.
-sOutputFile="\\spool\printer_name"
Specifies which printer should be used. The printer_name should be typed exactly as it appears in the Printers control panel, including spaces.

Supported options (device properties)

Several extra options exist which cannot be set through the command-line, but only by executing the appropriate PostScript setup code. These options can be set through the inclusion of a setup file on the command-line:

gs ... setup.ps ...

The setup.ps file is responsible for the device selection, therefore you should not specify the -sDEVICE=mswinpr2 option on the command-line if you are using such a setup file. Here is an example of such a setup file:

mark
  /NoCancel      true                       % don't show the cancel dialog
  /BitsPerPixel  4                          % force 4 bits/pixel
  /UserSettings
    <<
      /DocumentName  (Ghostscript document) % name for the Windows spooler
      /MaxResolution 360                    % maximum document resolution
    >>
  (mswinpr2) finddevice                     % select the Windows device driver
  putdeviceprops
setdevice

This example disables the progress dialog (same as the -dNoCancel option), forces a 4 bits/pixel output resolution and specifies additional user settings, such as the document name (which will be displayed by the Windows spooler for the queued document) and the maximum resolution (here 360 dpi). It then finds and selects an instance of the MS Windows device printer and activates it. This will show the standard printer dialog, since no /OutputFile property was specified.

The following options are available:

/NoCancel boolean
Disables (hides) the progress dialog when set to true or show the progress dialog if not set or set to false.
/OutputFile string
Specifies which printer should be used. The string should be of the form \\spool\printer_name, where the printer_name should be typed exactly as it appears in the Printers control panel, including spaces.
/QueryUser integer
Shows the standard printer dialog (1 or any other value), shows the printer setup dialog (2) or selects the default Windows printer without any user interaction (3).
/BitsPerPixel integer
Sets the device depth to the specified bits per pixel. Currently supported values are 1 (monochrome), 4 (CMYK with screening handled by Ghostscript) and 24 (True Color, dithering handled by the Windows printer driver; this option can produce huge print jobs).
/UserSettings dict
Sets additional options, defined in a dictionary. The following properties can be set:
/DocumentName string
Defines the user friendly document name which will be displayed by the Windows spooler.
/DocumentRange [n1 n2]
Defines the range of pages contained in the document. This information can be used by the printer dialog, in conjunction with the following property.
/SelectedRange [n1 n2]
Defines the selected range of pages. This information will be displayed in the printer dialog and will be updated after the user interaction. A PostScript program could check these values and print only the selected page range.
/MaxResolution dpi
Specifies the maximum tolerated output resolution. If the selected printer has a higher resolution than dpi, then Ghostscript will render the document with a submultiple of the printer resolution. For example, if MaxResolution is set to 360 and the output printer supports up to 1200 dpi, then Ghostscript renders the document with an internal resolution of 1200/4=300 dpi. This can be very useful to reduce the memory requirements when printing in True Color on some high resolution ink-jet color printers.

These properties can be queried through the currentpagedevice operator. The following PostScript code snippet shows how to do it for some of the properties:

currentpagedevice /BitsPerPixel get ==  % displays the selected depth

currentpagedevice /UserSettings get     % get the additional options..
/us exch def                            % ..and assign them to a variable

us /DocumentName get ==     % displays the document name
us /SelectedRange get ==    % displays the selected page range

% other misc. informations (don't rely on them)

us /Color get ==            % 1 => monochrome output, 2 => color output
us /PrintCopies get ==      % displays the number of copies requested

There are a few undocumented informations stored in the UserSettings dictionary. You should not rely on them. Their use is still experimental and they could be removed in a future version.

Duplex printing

If the Windows printer supports the duplex printing feature, then it will also be available through the mswinpr2 device. You can query for this support through the /Duplex propery of the currentpagedevice. If it returns null, then the feature is not supported by the selected printer. Otherwise, true means that the printer is currently set up to print on both faces of the paper and false that it is not, but that it can.

The following example shows how to print on both faces of the paper (using the long side of the paper as the reference):

<< /Duplex true /Tumble false >> setpagedevice


JPEG file format (JFIF)

Ghostscript includes output drivers that can produce Independent JPEG Group JFIF (JPEG File Interchange Format) files from PostScript images. Please note that JPEG is a compression method specifically intended for continuous-tone images such as photographs, not for graphics, and it is therefore quite unsuitable for the vast majority of page images produced with PostScript, which should be saved in a form better for graphics, such as Portable Network Graphics (PNG) format. If you get crummy-looking JPEG files, don't blame Ghostscript; instead consult a reference about uses and abuses of JPEG, such as the JPEG FAQ

http://www.faqs.org/faqs/jpeg-faq/

You can use the JPEG output drivers -- jpeg to produce color JPEG files and jpeggray for grayscale JPEGs -- the same as other file-format drivers: by specifying the device name and an output file name, for example

gs -sDEVICE=jpeg -sOutputFile=foo.jpg foo.ps

You can also use the -r switch to specify the imaging resolution and thus the output file's size in pixels. The default resolution is normally 72×72dpi.

The JPEG devices support several special parameters to control the JPEG "quality setting" (DCT quantization level).

-dJPEGQ=N (integer from 0 to 100, default 75)
Set the quality level N according to the widely used IJG quality scale, which balances the extent of compression against the fidelity of the image when reconstituted. Lower values drop more information from the image to achieve higher compression, and therefore have lower quality when reconstituted.
-dQFactor=M (float from 0.0 to 1.0)
Adobe's QFactor quality scale, which you may use in place of JPEGQ above. The QFactor scale is used by PostScript's DCTEncode filter but is nearly unheard-of elsewhere.

At this writing the default JPEG quality level of 75 is equivalent to -dQFactor=0.5, but the JPEG default might change in the future. The JPEG drivers could be extended to support additional JPEG compression options, such as the other DCTEncode filter parameters, but so far they haven't been.


H-P 8xx, 1100, and 1600 color inkjet printers

This section, written by Uli Wortmann <uliw@erdw.ethz.ch>, deals with the DeskJet 670, 690, 850, 855, 870, 890, 1100, and 1600.

Drivers contained in gdevcd8.c

The source module gdevcd8.c contains four generic drivers:

cdj670      HP DeskJet 670 and 690
cdj850   HP DeskJet 850, 855, 870, and 1100
cdj890   HP DeskJet 890
cdj1600   HP DeskJet 1600

Further documentation

Credits: Much of the driver is based on ideas derived from the cdj550 driver of George Cameron. The support for the hp670, hp690, hp890 and hp1600 was added by Martin Gerbershagen.

11.11.96     Version 1.0      
25.08.97   Version 1.2   Resolved all but one of the known bugs, introduced a couple of perfomance improvements. Complete new color-transfer-function handling (see gamma).
01.06.98   Version 1.3   Due to the most welcome contribution of Martin Gerbershagen (ger@ulm.temic.de), support for the hp670, hp690 and hp890 and hp1600 has been added. Martin has also resolved all known bugs.
        Problems:Dark colors are still pale.

The hp690 is supported through the hp670 device, the hp855, hp870 and the hp1100 through the hp850 device. The driver needs no longer special switches to be invoked except -sDEVICE=cdj850, -sDEVICE=CDJ890, -sDEVICE=CDJ670, or -sDevice=CDJ1600. The following switches are supported.

-dPapertype=     0     plain paper [default]
  1   bond paper
  2   special paper
  3   glossy film
  4   transparency film
      Currently the lookup tables are unsuited for printing on special paper or transparencies. For these please revert to the gamma functions.
-dQuality=   -1   draft
  0   normal [default]
  1   presentation
-dRetStatus=   0   C-RET off
  1   C-RET on [default]
-dMasterGamma=   3.0   [default = 1.0]
Note: To take advantage of the calibrated color-transfer functions, be sure not to have any gamma statements left! If you need to (i.e., for overhead transparencies), you still can use the gamma functions, but they will override the built-in calibration. To use gamma in the traditional way, set MasterGamma to any value greater than 1.0 and less than 10.0. To adjust individual gamma values, you have to additionally set MasterGamma to a value greater than 1.0 and less than 10.0. With the next release, gamma functions will be dropped.

When using the driver, be aware that printing at 600dpi involves processing large amounts of data (> 188MB !). Therefore the driver is not what you would expect to be a fast driver ;-) This is no problem when printing a full-sized color page (because printing itself is slow), but it's really annoying if you print only text pages. Maybe I can optimize the code for text-only pages in a later release. Right now, it is recommended to use the highest possible optimisation level your compiler offers. For the time being, use the cdj550 device with -sBitsPerPixel=3 for fast proof prints. If you simply want to print 600dpi BW data, use the cdj550 device with -sBitsPerPixel=8 (or 1).

Since the printer itself is slow, it may help to set the process priority of the gs process to "regular" or even less. On a 486/100MHz this is still sufficient to maintain a continuous data flow. Note to OS/2 users: simply put the gs window into the background or minimize it. Also make sure that print01.sys is invoked without the /irq switch (great speed improvement under Warp4).

The printer default settings compensate for dot-gain by a calibrated color-transfer function. If this appears to be too light for your business graphs, or for overhead transparencies, feel free to set -dMasterGamma=1.7. Furthermore, you may tweak the gamma values independently by setting -dGammaValC, -dGammaValM, -dGammaValY or -dGammaValK (if not set, the values default to MasterGamma). This will only work when -dMasterGamma is set to a value greater than 1.0.

Further information, bugs, tips etc, can be found at my website. To learn more about gamma, see ftp://ftp.igd.fhg.de/pub/doc/colour/GammaFAQ.pdf.

Depending on how you transfer the files, under UNIX you may need to remove the CRs of the CR-LF sequence used for end-of-line on DOS-based (MS Windows-based) systems. You can do this in unpacking the files with unzip -a hp850.zip.

To compile with gs5.x or later, simply add to your makefile

DEVICE_DEVS4=cdj850.dev cdj670.dev cdj890.dev cdj1600.dev

Have fun!

Uli <uliw@erdw.ethz.ch>
http://www.erdw.ethz.ch/~bonk/


H-P 812, 815, 832, 880, 882, 895, and 970 color inkjet printers

This section, written by Matthew Gelhaus <mgelhaus@proaxis.com>, deals with the DeskJet 812, 815, 832, 880, 882, 895, and 970.

This is a modified version of the HP8xx driver written by Uli Wortmann. More information and download are available at http://www.proaxis.com/~mgelhaus/linux/software/hp880c/hp880c.html.

Drivers contained in gdevcd8.c

The source module gdevcd8.c contains one generic driver:

cdj880      HP DeskJet 812, 815, 832, 880, 882, 895, and 970

Further documentation

Credits: This driver is based on the cdj850 driver by Uli Wortmann, and shares the same internal structure, although the PCL3+ interpretation has changed.

15.03.99     Version 1.3     Initial version, based on Version 1.3 of Uli Wortmann's driver.
26.02.00   Version 1.4beta   Greatly improved color handling & dithering, but not yet complete enough to use for text.

All printers are supported through the cdj880 device. Invoke with -sDEVICE=cdj880. The following switches are supported.

-dPapertype=     0     plain paper [default]
  1   bond paper
  2   special paper
  3   glossy film
  4   transparency film
      Currently the lookup tables are unsuited for printing on special paper or transparencies. For these please revert to the gamma functions.
-dQuality=   -1   draft
  0   normal [default]
  1   presentation
-dMasterGamma=   3.0   [default = 1.0]

The printer default settings compensate for dot-gain by a pre-defined color-transfer function. If this appears to be too light for your business graphs, or for overhead transparencies, feel free to set -dMasterGamma=1.7. Furthermore, you may tweak the gamma values independently by setting -dGammaValC, -dGammaValM, -dGammaValY or -dGammaValK (if not set, the values default to MasterGamma). This will only work when -dMasterGamma is set to a value greater than 1.0.

Further information, bugs, tips etc, can be found at my website.

To compile with gs6.x or later, simply add to your makefile

DEVICE_DEVS4=$(DD)cdj880.dev

Matthew Gelhaus <mgelhaus@proaxis.com>
http://www.proaxis.com/~mgelhaus


H-P color inkjet printers

This section, written by George Cameron, deals with the DeskJet 500C, DeskJet 550C, PaintJet, PaintJet XL, PaintJet XL300, the DEC LJ250 operating in PaintJet-compatible mode.

Drivers contained in gdevcdj.c

The source module gdevcdj.c contains six generic drivers:

cdj500      HP DeskJet 500C and 540C
cdj550   HP DeskJet 550C, 560C, 660C, 660Cse
pjxl300   HP PaintJet XL300, DeskJet 1200C, and CopyJet
pjtest   HP PaintJet
pjxltest   HP PaintJet XL
declj250   DEC LJ250

All these drivers have 8-bit (monochrome), 16-bit and 24-bit (colour) and for the DJ 550C, 32-bit (colour, CMYK mode) options in addition to standard colour and mono drivers. It is also possible to set various printer-specific parameters from the command line, for example

gs -sDEVICE=cDeskJet -dBitsPerPixel=16 -dDepletion=1 -dShingling=2 tiger.ps

Note: the old names cDeskJet, cdjcolor and cdjmono drivers have been retained; however, their functionality duplicates that available using the drivers above (and cDeskJet is identical to cdj500). That is, we can use

gs -sDEVICE=cdj500 -dBitsPerPixel=24     for cdjcolor, and
gs -sDEVICE=cdj500 -dBitsPerPixel=1   for cdjmono

Default paper size

If the preprocessor symbol A4 is defined, the default paper size is ISO A4; otherwise it is U.S. letter size (see about paper sizes in the usage documentation). You can specify other paper sizes on the command line, including A3 for the PaintJet XL and PaintJet XL300, as also explained in the usage documentation.

DeskJet physical limits

The DeskJet's maximum printing width is 2400 dots, or 8 inches (20.32cm). The printer manuals say that the maximum recommended printing height on the page is 10.3 inches (26.16cm), but since this is obviously not true for A4 paper, and I have been unable to detect any problems in printing longer page lengths, this would seem to be a rather artificial restriction.

All DeskJets have 0.5 inches (1.27cm) of unprintable bottom margin, due to the mechanical arrangement used to grab the paper. Side margins are approximately 0.25 inches (0.64cm) for U.S. letter paper, and 0.15 inches (0.38cm) for A4.

Printer properties (command-line parameters)

Several printer "properties" have been implemented for these printers. Those available so far are all integer quantities, and thus may be specified, for instance, like

gs -dBitsPerPixel=32 -dShingling=1 ...

which sets the BitsPerPixel parameter to 32 and the Shingling parameter to 1.

Bits per pixel

If the preprocessor symbol BITSPERPIXEL is defined as an integer (see below for the range of allowable values), that number defines the default bits per pixel (bit depth) for the generic drivers. If the symbol is undefined, the default is 24 bits per pixel. It is, of course, still possible to specify the value from the command line as described below. Note also that the cDeskJet, cdjcolor and cdjmono drivers are unaffected by setting this symbol, as their default settings are predefined to be 1, 3 and 24 respectively.

All of the drivers in gdevcdj.c accept a command line option to set the BitsPerPixel property. This gives considerable flexibility in choosing various tradeoffs among speed, quality, colour, etc. The valid numbers are:

1
A standard Ghostscript monochrome driver, using black ink (by installing the separate mono cartridge in the case of the DeskJet 500C, or automatically for the other printers).
3
A standard Ghostscript colour driver, using internal dithering. This is fast to compute and to print, but the clustered dithering can lose some detail and colour fidelity.
8
An "error-diffusion" monochrome driver which uses Floyd-Steinberg dithering to print greyscale images. The patterns are much more randomised than with the normal clustered dithering, but the data files can be much larger and somewhat slower to print.
16
A "cheaper" version of the 24-bit driver, which generates Floyd-Steinberg colour dithered output using the minimum memory (this may be helpful when using Ghostscript has not been compiled using a 16-bit build environment). The quality can be almost as good as the 24-bit version.
24
A high-quality colour driver using Floyd-Steinberg dithering for maximum detail and colour range. However, it is very memory-intensive, and thus can be slow to compute. It tends to produce rather larger raw data files, so they can also take longer to print.
32
Only for the DeskJet 550C, which uses the black cartridge and the colour cartridge simultaneously (that is, CMYK printing). This printer can both be faster and give higher quality than the DeskJet 500C, because of the true black ink. (Note that the 24-bit mode also permits CMYK printing on this printer, and uses less memory. Any differences between 24-bit and 32-bit should be small.)

DeskJet properties

Name      Type       

BlackCorrect   int   Colour correction to give better blacks when using the DJ500C in colour mode. For example, the default of 4 reduces the cyan component to 4/5. Range accepted: 0 - 9 (0 = none).
Shingling   int   Interlaced, multi-pass printing: 0 = none, 1 = 50%, 2 = 25%, 2 is best and slowest.
Depletion   int   "Intelligent" dot-removal: 0 = none, 1 = 25%, 2 = 50%, 1 best for graphics? Use 0 for transparencies.

PaintJet XL300 / PaintJet XL properties

Name      Type     

PrintQuality   int   Mechanical print quality: -1 = fast, 0 = normal, 1 = presentation. Fast mode reduces ink usage and uses single-pass operation for some media types. Presentation uses more ink and the maximum number of passes, giving slowest printing for highest quality
RenderType   int  
0
driver does dithering
1
snap to primaries
2
snap black to white, others to black
3
ordered dither
4
error diffusion
5
monochrome ordered dither
6
monochrome error diffusion
7
cluster ordered dither
8
monochrome cluster ordered dither
9
user-defined dither (not supported)
10
monochrome user-defined dither ns.

The PaintJet (non-XL) has no additional properties.

Gamma correction

One consequence of using Floyd-Steinberg dithering rather than Ghostscript's default clustered ordered dither is that it is much more obvious that the ink dots are rather larger on the page than their nominal 1/180-inch or 1/300-inch size (clustering the dots tends to minimise this effect). Thus it is often the case that the printed result is rather too dark. A simple empirical correction for this may be achieved by preceding the actual PostScript file to be printed by a short file which effectively sets the gamma for the device, such as

gs ... gamma.ps colorpic.ps -c quit

where gamma.ps is

%!
/.fixtransfer {
  currentcolortransfer 4 {
    mark exch
    dup type dup /arraytype eq exch /packedarraytype eq or
    1 index xcheck and { /exec load } if
    0.333 /exp load
    ] cvx 4 1 roll
  } repeat setcolortransfer
} bind odef
.fixtransfer
/setpagedevice { setpagedevice .fixtransfer } bind odef

This does the gamma correction after whatever correction the device might be doing already. To do the correction before the current correction,

%!
/.fixtransfer {
  currentcolortransfer 4 {
    mark 0.333 /exp load 4 -1 roll
    dup type dup /arraytype eq exch /packedarraytype eq or
    1 index xcheck and { /exec load } if
    ] cvx 4 1 roll
  } repeat setcolortransfer
} bind odef
.fixtransfer
/setpagedevice { setpagedevice .fixtransfer } bind odef

This example sets the gamma for R, G, and B to 3, which seems to work reasonably well in practice.

HP's resolution-enhanced mode for Inkjet printers

This feature is available on HP's more recent inkjet printers, including the DeskJet 520 (mono), 540 (mono or colour) and 560C (mono and colour). The colour and monochrome drivers for the HP DeskJet 550c are (probably) the best you will get for use with Ghostscript, for the following reasons.

These printers do not offer true 600×300dpi resolution. Those that print in colour are strictly 300×300dpi in colour mode, while in mono mode there is a pseudo 600×300dpi mode with the restriction that you can't print two adjacent dots. In effect what you have is 600dpi dot positioning, but on average you don't get more dots per line. This provides the possibility, for instance, to have sharper character outlines, because you can place dots on the edges nearer to their ideal positions. This is why it is worth doing.

However, HP will not support user-level programming of this resolution-enhanced mode, one reason being that (I understand) all the dot spacing has to be done by the driver, and if you get it wrong, you can actually damage the print head.

To summarise, you may lose a smidgin of (potential) text clarity using the 550c drivers (cdj550, cdjcolor, cdjmono etc.), but other than that, they are the ones for the job.

General tips

For all the printers above, the choice of paper is critically important to the final results. The printer manuals suggest type of paper, but in general, smoother, less fibrous types give better results. In particular, the special ink-jet paper can make a big difference: colours are brighter, but most importantly, there is almost no colour bleed, even with adjacent areas of very heavy inking. Similarly the special coated transparencies also work well (and ordinary transparencies do not work at all!).

The Unix procedure unix-lpr.sh provides one example of setting up a multi-option colour PostScript lpr queue on Unix systems, and includes the ability to choose a range of different colour options and printer accounting and error logging.

Caveat emptor! It is not always easy for me to test all of these drivers, as the only colour printer I have here is the DeskJet 500C. I rely on others to test drivers for the additional machines and report their findings back to me.


Canon BubbleJet (BJC) printers

This section was contributed by the author of the drivers, Yves Arrouye <yves.arrouye@usa.net>. The drivers handle Canon BJC-600, BJC-4xxx, BJC-70, Stylewriter 2x00, and BJC-800 printers.

History

The BJC-600 driver was written in the first place by Yoshio Kuniyoshi and later modified by Yves Arrouye <yves.arrouye@usa.net>. We tried to make it evolve synchronously, though Yoshio cannot be reached since a long time ago. The drivers are based on code for the HP printers by George Cameron (in fact, they are in the same file!), so he's the first person to thank.

The 2.00 version of the drivers was a complete rewrite of the driver (arguments, optimization, colour handling, in short: everything!) by Yves Arrouye. That release was also the first one to be able to use the full width of an A3 paper size. PostScript Printer Description (PPD) files for the drivers were released with version 2.15. They are incomplete, but they can be used to drive the printers' main features.

Configuring and building the BJC drivers

Modify values in gdevbjc.h

Configure the drivers by modifying the default values in the file gdevbjc.h or on the compilation line. If you don't do that, the drivers use reasonable defaults that make them work "as expected". All default values shown here are defined in that file.

CMYK-to-RGB color conversion

By default, the drivers use the same algorithm as Ghostscript to convert CMYK colors to RGB. If you prefer to use Adobe formulas, define USE_ADOBE_CMYK_RGB when compiling. (See the top of the file gdevcdj.c to see the difference between the two.)

Vertical centering of the printable area

The drivers center the imageable area horizontally but not vertically, so that what can be printed does use the most of the output media. If you define BJC_DEFAULT_CENTEREDAREA when compiling, then the top and bottom margins will be the same, resulting in a (smaller) vertically centered imageable area also.

Page margins

If you define USE_RECOMMENDED_MARGINS, then the top and bottom margins will be the same (that is, BJC_DEFAULT_CENTEREDAREA will be defined for you) and the margins will be the 12.4mm recommended by Canon. Since margins are complicated (because one must rely on the mechanical precision of the printer), the drivers do something about the bottom margin: by default the bottom margin is 9.54mm for the BJC-600 driver and 7mm for the BJC-800. If you define USE_TIGHT_MARGINS, then the bottom margin is 7mm for both drivers (but I never managed to get my own BJC-600 to print a line on this low bound, hence the larger default). Regardless of the presence of this definition, USE_FIXED_MARGINS will not allow the BJC-800 to use the lower 7mm bottom margin, so if you have a problem with the bottom margin on a BJC-800, just define that (without defining USE_TIGHT_MARGINS, of course).

A quick way to be sure the margins you selected is to print a file whose contents are:

%!
clippath stroke showpage

If the margins are okay, you will get a rectangle visibly surrounding the printable area. If they're not correct, one or more of the sides will be either incomplete or completely unprinted.

Makefile and compilation

Make sure the bjc600 or bjc800 devices are in DEVICE_DEVS in the makefile; that is, look in the makefile for your platform and add them if necessary -- they may already be there. As of Ghostscript 5.10, for instance, one makefile has

DEVICE_DEVS6=bj10e.dev bj200.dev bjc600.dev bjc800.dev

Use of the drivers

There are two drivers here. The "bjc600" one supports the BJC-600 and BJC-4xxx (maybe the BJC-70 as well) and the "bjc800" one supports the BJC-800 series. Remarks here that apply to both drivers use the name "bjc".

Supported Options and Defaults

Note: "options", "properties", and "parameters" designate the same thing: device parameters that you can change.

Giving an option an incorrect value causes an error. Unless stated otherwise, this error will be a rangecheckerror. Options may be set from the Ghostscript command line (using the -d and -s switches or other predetermined switches if they have an effect on the driver) or using the PostScript Level 2 setpagedevice operator if Ghostscript has been compiled with the level2 or level3 device (which it should ;-)). There are no special-purpose operators such as one was able to find in Level 1 printers.

The bjc uses 24 bits per pixel by default (unless you change the value of BJC_BITSPERPIXEL), corresponding to CMYK printing. Supported modes are 1 bpp and 4 bpp (gray levels), 8 bpp, 16 bpp, 24 bpp and 32 bpp (colours). Colours are preferably stored in the CMYK model (which means, for example, that with 16 bpp there are only 16 different shades of each color) but it is possible to store them as RGB color for some depths. Some modes do Floyd-Steinberg dithering and some don't, but use the default Ghostscript halftoning (in fact, when halftoning is used, dithering takes also place but because of the low point density it is usually not efficient, and thus invisible).


Descriptions of printing modes by bpp and Colors
bpp     Colors     Mode

32   4   CMYK colour printing, Floyd-Steinberg dithering
24   4   The same. (But each primary colour is stored on 6 bits instead of 8.)
24   3   RGB colour printing, Floyd-Steinberg dithering. This mode does not use the black cartridge (that's why it exists, for when you don't want to use it ;-)). Each primary colour is stored in 8 bits as in the 32/4 mode, but black generation and under-color removal are done on the driver side and not by Ghostscript, so you have no control over it. (This mode is no longer supported in this driver.)
16   4   CMYK colour printing, halftoned by Ghostscript. F-S dithering is still visible here (but the halftone patterns are visible too!).
8   4   The same. (But each primary colour is stored in 2 bits instead of 4.)
8   3   RGB colour printing. This mode is not intended for use. What I mean is that it should be used only if you want to use custom halftone screens and the halftoning is broken using the 8/4 mode (some versions of Ghostscript have this problem).
8   1   Gray-level printing, Floyd-Steinberg dithering
1   1   Gray-level printing halftoned by Ghostscript

These modes are selected using the BitsPerPixel and Colors integer options (either from the command line or in a PostScript program using setpagedevice). See below.

A note about darkness of what is printed: Canon printers do print dark, really. And the Floyd-Steinberg dithering may eventually darken your image too. So you may need to apply gamma correction by calling Ghostscript as in

gs -sDEVICE=bjc600 gamma.ps myfile.ps

where gamma.ps changes the gamma correction (here to 3 for all colors); 0.45 gives me good results, but your mileage may vary. The bigger the value the lighter the output:

{ 0.45 exp } dup dup currenttransfer setcolortransfer

The drivers support printing at 90dpi, 180dpi and 360dpi. Horizontal and vertical resolutions must be the same or a limitcheck error will happen. A rangecheck will happen too if the resolution is not 90 ×2^N. If the driver is compiled with -DBJC_STRICT a rangecheck also happens if the resolution is not one of those supported. This is not the case, as we expect that there may be a 720dpi bjc some day.

Here are the various options supported by the bjc drivers, along with their types, supported values, effects, and usage:

BitsPerPixel (int)
Choose the depth of the page. Valid values are 1, 8, 16, 24 (the default) and 32.

Note that when this is set for the first time, the Colors property is automatically adjusted unless it is also specified. The table here shows the corresponding color models and the rendering method visible: "GS" for Ghostscript halftoning and "F-S" for Floyd-Steinberg dithering. When both are present it means that the dithering of halftones is visible. Default choices are indicated by asterisk "*".


Valid Colors values for
allowed BitsPerPixel values

bpp      Colors             Color model      Dithering

32   4       CMYK   F-S
24   4   *   CMYK   F-S
    3       RGB   F-S
16   4       CMYK   GS, F-S
8   4   *   CMYK   GS
    3       RGB   GS
    1       K (CMYK)   F-S
1   1   *   K (CMYK)   GS

Also note that automagical change of one parameter depending on the other one does not work in a setpagedevice call. This means that if you want to change BitsPerPixel to a value whose valid Colors values do not include the actual Colors value, you must change Colors too.

Colors (int)
Choose the number of color components from among 1, 3 and 4 (the default). This setting cannot be used in a PostScript program, only on Ghostscript's command line. See ProcessColorModel below for what to use to change the number of colors with PostScript code.

Note that setting this property does limit the choices of BitsPerPixel. As for the previous property, its first setting may induce a setting of the "other value" (BitsPerPixel here). The table here indicates valid combinations with "V", default values with asterisk "*".


Valid BitsPerPixel values
for allowed Colors values

        BitsPerPixel OK values
Colors    Type    32    24    16    8    1

4   CMYK   V   *   V   V    
3   RGB       *       V    
1   K               V   *

Also note that automagical change of one parameter depending on the other one does not work in a setpagedevice call. This means that if you want to change Colors to a value whose valid BitsPerPixel values don't include the actual BitsPerPixel value, you must change BitsPerPixel too.

ProcessColorModel (symbol)
A symbol taken from /DeviceGray, /DeviceRGB or /DeviceCMYK which can be used to select 1, 3 or 4 colors respectively. Note that this parameter takes precedence over Colors, and that both affect the same variable of the driver. (See Colors above for values combined with BitsPerPixel.)
HWResolution (floats array)
An array of two floats giving the horizontal and vertical resolution in dots per inch from among 90, 180 and 360 (the default). Both values must be the same. On the Ghostscript command line, the resolution may be changed with the -r switch.
ManualFeed (bool)
Indicate that the sheets won't be fed automatically by the printer, false by default. (Not meaningful on the BJC-600, I fear.)
MediaType (string)
The media to print on, chosen from among "PlainPaper", "CoatedPaper", "TransparencyFilm", "Envelope", "Card" and "Other". Default is "PlainPaper". For "Envelope", "Card" or "Other" the driver puts the printer into thick mode automatically regardless of the actual media weight.
MediaWeight (int or null)
The weight of the media in grams per square meter. Null (the default) indicates that the weight is of no importance. If the specified media weight is greater than 105 (that is, the value of the compilation default BJC???_MEDIAWEIGHT_THICKLIMIT) then the printer will be set to use thick paper.
PrintQuality (string)
The quality of printing.
Value    bjc600    bjc800     

Low       X   Has the effect of making only two printing passes instead of four, so should be twice the speed; known as "CN" (Color Normal) mode
Draft   X   X   Unlights the "HQ" light on a BJC-600
Normal   X   X   Default for both drivers; lights the "HQ" light on a BJC-600
High   X   X   Means 200% black and 100% CMY; lights the "Bk+" light on a BJC-600
DitheringType (string)
Dithering algorithm from between "Floyd-Steinberg" and "None". "None" is the default for 1/1 print mode, "Floyd-Steinberg" for other modes. At the moment this parameter is read-only, though no error is generated if one tries to change it. This parameter is not of much value at the moment and is here mainly to reserve the name for future addition of dithering algorithms.
PrintColors (int)
Mask for printing color. If 0, use black for any color; otherwise the value must be the sum of any of 1 (cyan), 2 (magenta), 4 (yellow) and 8 (black), indicating which colors will be used for printing. When printing colour, only colours specified will be printed (this means that some planes will be missing if a color's value above is omitted). When printing grays, black is used if it is present in the PrintColors; otherwise, the image is printed by superimposing each requested color.
MonochromePrint (bool)
For bjc600 only, false by default. Substitute black for Cyan, Magenta and Yellow when printing -- useful, for example, to get some monochrome output of a dithered printing This is a hardware mechanism as opposed to the previous software one. I think that using this or setting PrintColors to 0 will give the same results.

Note that the MediaType and ThickMedia options will be replaced by the use of the device InputAttributes and OutputAttributes as soon as possible. Please note too that the print mode may be reset at the start of printing, not at the end. This is the expected behaviour. If you need to reset the printer to its default state, simply print a file that does just a showpage.

Device information

Here is other information published by the driver that you will find in the deviceinfo dictionary.

OutputFaceUp (bool)
This has the boolean value true, indicating that the sheets are stacked face up.
Version (float)
In the form M.mmpp, where M is the major version, mm the bjc driver's minor version, and pp the specific driver minor version (that is, M.mm will always be the same for the bjc600 and bjc800 drivers).
VersionString (string)
A string showing the driver version and other indications. At the moment, things like "a" or "b" may follow the version to indicate alpha or beta versions. The date of the last change to this version is given in the form MM/DD/YY (no, it won't adapt to your locale).

Hardware margins

The BJC printers have top and bottom hardware margins of 3mm and 7.1mm respectively (Canon says 7mm, but this is unusable because of the rounding of paper sizes to PostScript points). The left margin is 3.4mm for A4 and smaller paper sizes, 6.4mm for U.S. paper sizes, envelopes and cards. It is 4.0mm for A3 paper on the BJC-800.

The maximum printing width of a BJC-600 printer is 203mm. The maximum printing width of a BJC-800 printer is 289mm on A3 paper, 203mm on U.S. letter and ISO A4 paper.

PostScript printer description (PPD) files

The files CBJC600.PPD and CBJC800.PPD (whose long names are, respectively, Canon_BubbleJetColor_600.ppd and Canon_BubbleJetColor_800.ppd) are PPD files to drive the features of the bjc600 and bjc800 drivers. They can be used, for example, on NextStep systems (presumably on OpenStep systems too) and on Unix systems with Adobe's TranScript and pslpr (not tested). The files are not complete at the moment. Please note that NextStep's printing interface does not correctly enforce constraints specified in these files (in UIConstraints descriptions): you must force yourself to use valid combinations of options.

Customizing the PPD files

By default the PPD files are set for U.S. letter size paper, and they use a normalized transfer function. If you choose to use A4 printing by default, you must replace "Letter" with "A4" in these (noncontiguous) lines:

     [...]
*DefaultPageSize: Letter
     [...]
*DefaultRegion: Letter
     [...]
*DefaultImageableArea: Letter
     [...]

Some versions of Ghostscript have problems with normalized colors, which makes them add magenta in gray levels. If you experience this problem, in the PPD file replace the line

*DefaultTransfer: Normalized

with the alternate line

*DefaultTransfer: Null

The "thick media" option is implemented by choosing a value of 120 or 80 (for thick and thin media respectively) for the MediaWeight feature of the drivers. If you ever change the threshold for thick media in the driver code, you may need to change the values in the PPD files too.

All customization should be done using the "*Include:" feature of PPD files so that your local changes will be retained if you update the PPD files.

How to report problems

If you have problems with this driver (or if you are extremely satisfied with it, you may email me directly at <yves.arrouye@usa.net>. When you report a problem please be as descriptive as possible, and please send information that can be used to reproduce the problem. Don't forget to say which driver you use, and in what version. Version information can be found in the source code of the driver or by issuing the following command in a shell:

echo "currentpagedevice /VersionString get ==" | gs -q -sDEVICE=bjc600 -

Acknowledgements

I am particularly grateful to Yoshio Kuniyoshi <yoshio@nak.math.keio.ac.jp> without whom I'd never make these drivers, and also to L. Peter Deutsch, who answered all my (often silly) questions about Ghostscript's driver interface.

Thanks also to the people who volunteered to beta-test the v2.x BJC drivers: David Gaudine <david@donald.concordia.ca>, Robert M. Kenney <rmk@unh.edu>, James McPherson <someone@erols.com> and Ian Thurlbeck <ian@stams.strath.ac.uk> (listed alphabetically) were particularly helpful by discovering bugs and helping find out exact paper margins on printers I don't have access to.

And many thanks to Klaus-Gunther Hess <ghess@elmos.de> for looking at the dithering code and devising a good CMYK dithering algorithm for the Epson Stylus Color, which I then adapted to the code of these drivers.


Epson Stylus color printer (see also uniprint)

This section was contributed by Gunther Hess <ghess@elmos.de>, who also wrote uniprint, a later set of drivers. You should probably see the section on uniprint for whether it might be better for your uses than this driver.

Usage

This driver is selected with "-sDEVICE=stcolor", producing output for an Epson Stylus Color at 360dpi resolution by default. But it can do much more with this printer, and with significantly better quality, than with the default mode; and it can also produce code for monochrome versions of the printer. This can be achieved via either command-line options or Ghostscript input. For convenience a PostScript file is supplied for use as an initial input file. Try the following command:

gs -sDEVICE=stcolor -r{Xdpi}x{Ydpi} stcolor.ps {YourFile.ps}

where {Xdpi} is one of 180, 360, or 720 and {Ydpi} is one of 90, 180, 360, or 720. The result should be significantly better. You may use stcolor.ps with other devices too, but I do not recommend this, since it does nothing then. stcolor.ps should be available with binary distributions and should reside in the same directory as other Ghostscript initialization files or in the same directory as the files to be printed. Thus if Ghostscript is part of your printer-spooler, you can insert

(stcolor.ps) findlibfile { pop run } if pop

in files you want to use the improved algorithms. You may want to adapt stcolor.ps file to your specific needs. The methods and options for this are described here, but this description is restricted to Ghostscript options, while their manipulation at the PostScript level is documented in the material on the relationship of Ghostscript and PostScript and in stcolor.ps.

Options

Now to explain the options (as written on my UNIX system). The order is somehow related to their use during the printing process:

-dUnidirectional
Force unidirectional printing, recommended for transparencies
-dMicroweave
Enable the printer's "microweave" feature; see "What is weaving?" below.
-dnoWeave
Disable any Weaving (overrides -dMicroweave)
-dSoftweave
Enable the driver's internal weaving. Note that Softweave works only with the original Stylus Color and the PRO-Series.
-sDithering={name}
Select another dithering algorithm (name) from among
gscmyk      fast color output, CMYK process color model (default)
gsmono   fast monochrome output
gsrgb   fast color output, RGB process color model
fsmono   Floyd-Steinberg, monochrome
fsrgb   Floyd-Steinberg, RGB process color model (almost identical to the cdj550/bjc algorithm)
fsx4   Floyd-Steinberg, CMYK process color model (shares code with fsmono and fsrgb, but is algorithmically really bad)
fscmyk   Floyd-Steinberg, CMYK process color model and proper modifications for CMYK
hscmyk   modified Floyd-Steinberg with CMYK model ("hs" stands for "hess" not for "high speed", but the major difference from fscmyk is speed)
fs2   algorithm by Steven Singer (RGB) should be identical to escp2cfs2.
-dBitsPerPixel={1...32}
number of bits used for pixel storage; the larger the value, the better the quality -- at least in theory. In fsrgb one can gain some speed by restricting to 24 bits rather than the default 30.
-dFlag0
causes some algorithms to select a uniform initialisation rather than a set of random values. May yield a sharper image impression at the cost of dithering artifacts. (Applies to hscmyk and all fs modes, except for fs2, which always uses a constant initialization.)
-dFlag1 ... -dFlag4
Available for future algorithms.
-dColorAdjustMatrix='{three, nine, or sixteen floating-point values}'
This is a matrix to adjust the colors. Values should be between -1.0 and 1.0, and the number of values depends on the color model the selected algorithm uses. In RGB and CMYK modes a matrix with 1.0 on the diagonal produces no transformation. This feature is really required, but I could not identify a similar feature at the language level, so I implemented it, but I don't know reasonable values yet.
-dCtransfer='{float float ...}' or
-dMtransfer=..., -dY..., -dK... or
-dRtransfer='{float float ...}' or
-dG..., -dB... or
-dKtransfer='{float float ...}'
Which you use depends on the algorithm, which may be either either CMYK, RGB or monochrome. The values are arrays of floats in the range from 0 to 1.0, representing the visible color intensity for the device. One may achieve similar effects with setcolortransfer at the language level, but this takes more time and the underlying code for the driver-specific parameters is still required. The size of the arrays is arbitrary and the defaults are "{0.0 1.0}", which is a linear characteristic. Most of the code in stcolor.ps are better transfer arrays.
-dKcoding='{float...}'
-dC..., -dM... etc.
Arrays between 0.0 and 1.0, controlling the internal coding of the color values. Clever use of these arrays may yield further enhancements, but I have no experience yet. (To be discontinued with version 2.x.)
-sModel=st800
Causes output to be suitable for the monochrome Stylus 800 (no weaving, no color).
-sOutputCode={name}
Can be either "plain", "runlength" or "deltarow" and changes the ESC/P2 coding technique used by the driver. The default is to use runlength encoding. "plain" selects uncompressed encoding and generates enormous amounts of data.
-descp_Band=1/8/15/24
Number of nozzles of scanlines used in printing, Useful only with -dnoWeave. Larger Values yield smaller code, but this doesn't increase the printing speed.
-descp_Width=N
Number of pixels Printed in each scan Line. (Useful only when tuning margins; see below)
-descp_Height=pixels
Length of the entire page in pixels. (Parameter of "ESC(C" in default initialization.)
-descp_Top=scan lines
Top margin in scan lines. (First parameter of "ESC(c" in default initialization.)
-descp_Bottom=scan lines
Bottom margin in scan lines. (Second parameter of "ESC(c" in default initialization.)
-sescp_Init="string"
Override for the initialization sequence. (Must set graphics mode 1 and units.)
-sescp_Release="string"
Overrides the release sequence, "ESC @ FF" by default.

ESC/P2 allows any resolutions to be valid in theory, but only -r360x360 (the default) and -r720x720 (not on STC-IIs ? and st800) are known to work with most printers.


Valid option combinations
Stylus I & Pro-Series only

Resolution      escp_Band      Weave usable      escp_Band &
number of passes

180x90   15   noWeave    
180x180   1 , 8, 24   noWeave, Microweave   15/2 SoftWeave
180x360           15/4 SoftWeave
180x720           15/8 SoftWeave
360x90   15   noWeave    
360x180   1, 8, 24   noWeave, Microweave   15/2 SoftWeave
360x360   1, 8, 24   noWeave, Microweave   15/4 SoftWeave
360x720           15/8 SoftWeave
720x90   15   noWeave    
720x180           15/2 SoftWeave
720x360           15/4 SoftWeave
720x720   1   noWeave, Microweave   15/8 SoftWeave
Beware: there are only few validity checks for parameters. A good example is escp_Band: if you set this, the driver uses your value even if the value is not supported by the printer. You asked for it and you got it!

Application note and FAQ

Quite a bunch of parameters. Hopefully you never need any of them, besides feeding stcolor.ps to Ghostscript in front of your input.

After answering some questions over fifty times I prepared a FAQ. Here is version 1.3 of the FAQ, as of stcolor version 1.20 (for Ghostscript 3.50).

Support for A3 paper

Yes, this driver supports the A3-size printer: merely set the required pagesize and margins. A simple way to do this is to specify the command-line switch "-sPAPERSIZE=a3" or include the procedure call "a3" in the PostScript prolog section. To optimize the printable area or set the proper margins, see the next paragraph.

Margins, PageSize

I refuse to add code to stcolor that tries to guess the proper margins or page size, because I found that such guessing is usually wrong and needs correction in either the source or the parameters. You can modify stcolor.ps to do that, however. After the line

mark % prepare stack for "putdeviceprops"

insert these lines, which define page size and margins in points:

/.HWMargins [9.0 39.96 12.6 9.0]     % Left, bottom, right, top (1/72")
/PageSize   [597.6 842.4]            % Paper, including margins (1/72")
/Margins [ % neg. Offset to Left/Top in Pixels
   4 index 0 get STCold /HWResolution get 0 get mul 72 div neg
   5 index 3 get STCold /HWResolution get 1 get mul 72 div neg
]

Feel free to change the values of .HWMargins and PageSize to match your needs; the values given are the defaults when the driver is compiled with "-DA4". This option or its omission may cause trouble: the Stylus Color can print up to exactly 8 inches (2880 pixels) at 360dpi. The remaining paper is the margin, where the left margin varies only slightly with the paper size, while the right margin is significantly increased for wider paper, such as U.S. letter size.

Note that if you are using an ISO paper size with a version of stcolor after 1.20 and compiled without "-DA4", then the default margin is too large, and you need to add the proper ".HWMargins" to the command line or to stcolor.ps.

Stylus Color II / IIs and 1500

First the good news: the driver can print on the Stylus Color II. Now the bad news:

To make things work, you MUST disable the driver's internal weaving (Softweave), in one of these two ways:

gs -dMicroweave ...
gs -dnoWeave -descp_Band=1 ...

Version 1.90, current as of Ghostscript 5.10, fixes this bug by new default behaviour. I experienced significantly increased printing speed with the second variant on the old Stylus Color, when printing mostly monochrome data.

Recommendations

The next section is a contribution from Jason Patterson <jason@reflections.com.au> who evaluated a previous version (1.17). Ghostscript was invoked as follows:

gs
-sDEVICE=stcolor -r720x720 -sDithering=... -sOutputFile=escp.out stcolor.ps whatsoever.ps

where "..." is the name of the desired algorithm. stcolor.ps was omitted for the gs-algorithms (gsmono, gsrgb and gscmyk), for which it is useless and would not allow the selection of "gscmyk".

Color dithering experiments with gdevstc 1.21

Here are data about the EPSON Stylus Color driver's different dithering methods, based on a little experiment using four good quality scanned images of quite varied nature, to begin with, a summary of the results of the four experiments. Sanity note: the results here are from only four images and a total of 24 printouts (eight on 720dpi paper, sixteen on plain paper). Your results will almost certainly vary, and your standards might not be the same as mine, so use these results only as a guide, not as a formal evaluation.


Quality of output by method
  

gsmono      Pretty much what you'd expect from a mono ordered pattern. Looks like what a lot of mono laser printers produce.
fsmono   Excellent for monochrome.
gscmyk   Not very good, but expected from an ordered pattern.
gsrgb   A little better than gscmyk. More consistent looking.
fs2   Good, but not quite as good as fsrgb. Gets the brightness wrong: too light at 720dpi, too dark at 360dpi.
fsrgb   Very good, but a little too dark and has a slight blue tint.
hscmyk   Excellent. Slightly better than fsrgb and fs2. Better than fscmyk on some images, almost the same on most.
fscmyk   Best. Very, very slightly better than hscmyk. On some images nearly as good as the EPSON demos done with the MS Windows driver.

Overall visual quality (1-10), best to worst
Monochrome
     fsmono    ******************
  gsmono   **********
      0 1 2 3 4 5 6 7 8 9 10

Colour
  fscmyk   *******************
  hscmyk   *******************
  fsrgb   ******************
  fs2   *****************
  gsrgb   **********
  gscmyk   *********
      0 1 2 3 4 5 6 7 8 9 10

Color transformation

In the initial version of the driver distributed with Ghostscript 3.33, the parameter "SpotSize" was the only way to manipulate the colors at the driver level. According to the parameters enumerated above, this has changed significantly with version 1.16 and above as a result an ongoing discussion about dithering algorithms and "false color" on the Epson Stylus Color. This initiated the transformation of the stcolor driver into a framework for different dithering algorithms, providing a generalized interface to the internal Ghostscript color models and the other data structures related to Ghostscript drivers.

The main thing such a framework should be able to do is to deliver the values the dithering algorithm needs; and since this directly influences the optical image impression, this transformation should be adjustable without the need for recompilation and relinking. In general the process can be described as follows:

ColorAdjustMatrix Coding   Transfer  
| Ghostscript color | => | Ghostscript raster | => | Dithering data |
|   |   | 1/2/4/8/16/32-bit |   |   |
| 1/3/4 16-bit values |   | 1/3/4 values |   | (arbitrary type) |

Due to the limitations on raster storage, information is lost in the first transformation step, except for the 16-bit monochrome mode. So any color adjustment should take place before this step and this is where the optional ColorAdjustMatrix works.

The first transformation step, called "coding", is controlled by the ?coding arrays. The decoding process expands the range of values expontentially to a larger range than that provided by the initial Ghostscript color model, and is therefore a reasonable place to make device- or algorithm-specific adjustments. This is where the ?transfer arrays are used. Array access might be not the fastest method, but its generality is superior, so this step is always based upon internally algorithm-specific array access. If 8 bits are stored per color component and if the algorithm uses bytes too, the second transformation is included within the first, which saves significant computation time when printing the data.

ColorAdjustMatrix

The driver supports different values for ProcessColorModel, which raises the need for different color adjustments. Here "CAM" stands for "ColorAdjustMatrix".

DeviceGray (three floats)
if ((r == g) && (g == b))
   K' = 1.0 - R;
else
   K' = 1.0 - CAM[0] * R + CAM[1] * G + CAM[2] * B;

According to the documentation on drivers, the latter (the "else" clause) should never happen.

DeviceRGB (nine floats)
if((r == g) && (g == b))
   R' = B' = G' = R;
else
   R' = CAM[0]*R + CAM[1]*G + CAM[2]*B;
   G' = CAM[3]*R + CAM[4]*G + CAM[5]*B;
   B' = CAM[6]*R + CAM[7]*G + CAM[8]*B;

The printer always uses four inks, so a special treatment of black is provided. Algorithms may take special action if R, G, and B are all equal.

DeviceCMYK (sixteen floats)
if((c == m) && (m == y))
   K' = max(C,K);
   C' = M' = Y' = 0;
else
   K  = min(C,M,Y);
   if((K > 0) && ColorAdjustMatrix_present) { => UCR
      C -= K;
      M -= K;
      Y -= K;
   }

   C' = CAM[ 0]*C + CAM[ 1]*M + CAM[ 2]*Y + CAM[ 3]*K;
   M' = CAM[ 4]*C + CAM[ 5]*M + CAM[ 6]*Y + CAM[ 7]*K;
   Y' = CAM[ 8]*C + CAM[ 9]*M + CAM[10]*Y + CAM[11]*K;
   K' = CAM[12]*C + CAM[13]*M + CAM[14]*Y + CAM[15]*K;

Again we have a special black treatment. "max(C,K)" was introduced because of a slight misbehaviour of Ghostscript, which delivers black under certain circumstances as (1,1,1,0). Normally, when no special black separation and undercolor removal procedures are defined at the PostScript level, either (C,M,Y,0) or (0,0,0,K) values are mapped. This would make the extended ColorAdjustMatrix quite tedious, and so during mapping, black separation is done for (C,M,Y,0) requests; and if there is a ColorAdjustMatrix, undercolor removal is used too. In other words the default matrix is:

1 0 0 1
0 1 0 1
0 0 1 1
0 0 0 1

and it is applied to CMYK values with separated and removed black. Raising the CMY coefficients while lowering the K coefficients reduces black and intensifies color. But be careful, because even small deviations from the default cause drastic changes.

If no ColorAdjustMatrix is set, the matrix computations are skipped. Thus the transformation reduces to range inversion in monochrome mode and black separation in CMYK mode.

RGB / CMYK coding and transfer, and BitsPerPixel

These two (groups of) parameters are arrays of floating-point numbers in the range 0.0 to 1.0. They control the truncation to the desired number of bits stored in raster memory (BitsPerPixel) and the ink density. The "truncation" may become a nonlinear function if any of the ?coding arrays is set. Assume the following Ghostscript invocation:

gs -sDEVICE=stcolor -sDithering=fscmyk -dBitsPerPixel=16 \
     -dKcoding='{ 0.0 0.09 0.9 1.0 }' \
     -dMcoding='{ 0.0 0.09 0.9 1.0 }' \
   -dKtransfer='{ 0.0 0.09 0.9 1.0 }' \
   -dYtransfer='{ 0.0 0.09 0.9 1.0 }'

We may have either or both of ?coding and ?transfer, giving four possible combinations. (These four combinations appear in the given example.) The resulting mapping appears in the following tables, where except for the internal Indices (4 components × 4 bits = 16 BitsPerPixel), all values are normalized to the range 0 to 1. The actual range is 0 to 65535 for the Ghostscript color and 0 to 16777215 for the ink values delivered to the fscmyk algorithm. Sorry for the bunch of numbers following, but you may try this example in conjunction with stcinfo.ps, which should give you a graphical printout of the following numbers when you issue a showpage command.

    Cyan
  Magenta
CI/15   gs_color_values   CI   Ink   gs_color_values   CI   Ink

0.000   0.000 - 0.062   0   0.000   -0.123 - 0.123   0   0.000
0.067   0.063 - 0.125   1   0.067   0.123 - 0.299   1   0.247
0.133   0.125 - 0.187   2   0.133   0.299 - 0.365   2   0.351
0.200   0.188 - 0.250   3   0.200   0.365 - 0.392   3   0.379
0.267   0.250 - 0.312   4   0.267   0.392 - 0.420   4   0.406
0.333   0.313 - 0.375   5   0.333   0.420 - 0.447   5   0.433
0.400   0.375 - 0.437   6   0.400   0.447 - 0.475   6   0.461
0.467   0.438 - 0.500   7   0.467   0.475 - 0.502   7   0.488
0.533   0.500 - 0.562   8   0.533   0.502 - 0.529   8   0.516
0.600   0.563 - 0.625   9   0.600   0.529 - 0.557   9   0.543
0.667   0.625 - 0.687   10   0.667   0.557 - 0.584   10   0.571
0.733   0.688 - 0.750   11   0.733   0.584 - 0.612   11   0.598
0.800   0.750 - 0.812   12   0.800   0.612 - 0.639   12   0.626
0.867   0.813 - 0.875   13   0.867   0.639 - 0.715   13   0.653
0.933   0.875 - 0.937   14   0.933   0.715 - 0.889   14   0.778
1.000   0.938 - 1.000   15   1.000   0.889 - 1.111   15   1.000

The difference between cyan and magenta is the presence of a coding array. The coding process must map a range of color values to each of the sixteen component indices. If no coding array is given, this is accomplished by dividing by 4096, equivalent to a right shift by 12 bits. The final ink density resides in the given interval and moves from the left to the right side from 0 to 15. For magenta there is a coding array and the ink value matches the center of the intervals. But the distribution of the mapped intervals follows the given coding array and is nonlinear in the linear color space of Ghostscript.

Now let us take a look at the case with transfer arrays:

    Yellow
  Black
CI/15   gs_color_values   CI   Ink   gs_color_values   CI   Ink

0.000   0.000 - 0.062   0   0.000   -0.123 - 0.123   0   0.000
0.067   0.063 - 0.125   1   0.018   0.123 - 0.299   1   0.067
0.133   0.125 - 0.187   2   0.036   0.299 - 0.365   2   0.133
0.200   0.188 - 0.250   3   0.054   0.365 - 0.392   3   0.200
0.267   0.250 - 0.312   4   0.072   0.392 - 0.420   4   0.267
0.333   0.313 - 0.375   5   0.090   0.420 - 0.447   5   0.333
0.400   0.375 - 0.437   6   0.252   0.447 - 0.475   6   0.400
0.467   0.438 - 0.500   7   0.414   0.475 - 0.502   7   0.467
0.533   0.500 - 0.562   8   0.576   0.502 - 0.529   8   0.533
0.600   0.563 - 0.625   9   0.738   0.529 - 0.557   9   0.600
0.667   0.625 - 0.687   10   0.900   0.557 - 0.584   10   0.667
0.733   0.688 - 0.750   11   0.920   0.584 - 0.612   11   0.733
0.800   0.750 - 0.812   12   0.940   0.612 - 0.639   12   0.800
0.867   0.813 - 0.875   13   0.960   0.639 - 0.715   13   0.867
0.933   0.875 - 0.937   14   0.980   0.715 - 0.889   14   0.933
1.000   0.938 - 1.000   15   1.000   0.889 - 1.111   15   1.000

Yellow uses a transfer array. There is no linear correspondence between the color and the ink values: this correspondence is defined through the given array. In other words, the transfer arrays define a nonlinear ink characteristic, which is exactly the same functionality that PostScript's "(color)transfer" function provides.

While for yellow the intervals match the intervals used with cyan, for black the intervals match the magenta intervals. But watch the correspondence between the CI/15 values and the ink density for black: this is a linear distribution in the ink domain.

Not a bad idea, I think. Consider the fs2 algorithm: it uses values in the range 0 to 255. If any transfer array were alone, some of the 256 possible values would never be used and others would be used for adjacent intervals several times. Establishing an identical coding array solves this problem, so the full potential of the algorithm is used.

Another useful feature of the coding arrays is that they are internally normalized to the range 0-1. In 720x720dpi mode the transfer arrays in stcolor.ps limit the dot density to about 50%, so these arrays end at 0.5 (and begin at 0.5 for RGB). Because of automatic normalization, these arrays can also be used as coding arrays. But of course in the fs2 case mentioned above, values from 0 to 127 will never be delivered to the algorithm, while values 128-255 are delivered for adjacent intervals.

To clarify the intended use of the three parameters (parameter groups), keep this in mind:

What is weaving?

The Epson Stylus Color has a head assembly that contains two physically identifiable heads, one for black and one for cyan, magenta, and yellow (CMY). This makes four "logical" heads, one for each color component. Each of these four heads has several jets at some vertical (Y) distance from one another, so several horizontal lines can be printed of a given color during one pass of the heads. From experience I think there are fifteen jets per color, spaced at 1/90in.

So the question arises of how to print at a Y resolution of 360dpi with 90dpi jets. Simply by division one gets 360dpi/90dpi = 4, which tells us that 4 passes of the head assembly are needed to achieve a Y resolution of 360dpi.

Weaving is the method of how the fifteen jets are used to print adjacent horizontal rows separated here by 1/360 inch:


Print-head jets used with and without weaving
    Weaving
     noWeave
  Pass 1   2   3   4   1   2   3   4
Row
0   jet 0   --   --   --   jet 0   --   --   --
1   --   jet 1   --   --   --   jet 0   --   --
2   --   --   jet 2   --   --   --   jet 0   --
3   --   --   --   jet 3   --   --   --   jet 0
4   jet 1   --   --   --   jet 1   --   --   --
5   --   jet 2   --   --   --   jet 1   --   --
6   --   --   jet 3   --   --   --   jet 1   --
...

Now let's assume that the dot diameter is different for each individual jet, but the average among the jets matches the desired resolution. With weaving, adjacent rows are printed by different jets, thus some averaging takes place. Without weaving, adjacent rows are printed by the same jet and this makes the dot diameter deviations visible as 1/90in stripes on the paper.

Print mode parameters

The parameters "Unidirectional", "Microweave", "noWeave", "OutputCode", "Model" and the given resolution control the data generated for the printer.

Unidirectional

Simply toggles the unidirectional mode of the printer. Setting "Unidirectional" definitely slows printing speed, but may improve the quality. I use this for printing transparencies, where fast head movement could smear the ink.

Microweave, noWeave and OutputCode=deltarow

The first are two booleans, which implies that four combinations are possible. Actually only three exist (if you don't count for deltarow): Softweave, Microweave, and noWeave. The first and second are functionally identical, the difference being whether the driver or the printer does the job.

In the default Softweave mode the driver sends the data properly arranged to the printer, while in Microweave mode, it is the printer that arranges the data. But in general the host processor is much faster than the printer's processor, and thus it is faster for the host do the job. In addition to that, for 720dpi eight passes are required, and the amount of buffer space needed to buffer the data for the passes is far beyond the printer's memory. Softweave requires an odd value of "escp_Band"; the Stylus Color provides fifteen for that.

"OutputCode" controls the encoding used. In the basic modes, the choice consists of "plain" and "runlength". The computation of runlength-encoded data does not take much time, less than the data tranfer to the printer; thus this is the recommended mode, and of course the default. With the Stylus Color, Epson introduced some new encoding principles, namely "tiff" and "deltarow". While the first was omitted from this driver for lack of apparent advantages, "deltarow" is available as an option. "Softweave" cannot be used with this encoding, so if OutputCode=deltarow is set, Microweave becomes the default. Maybe that the size of the ESC/P2 code becomes smaller, but I have never observed faster printing speed. Things tend to become slower with deltarow compared to Softweave.

Model

Some ESC/P2 printers such as the Stylus 800 do not offer Microweave or the commands required to do Softweave. Setting Model just changes the defaults and omits some parts of the initialization sequence which are not compatible with the given printer model. Currently only "st800" is supported besides the default stcolor.

Bugs and pitfalls

Tests

This section gives an overview of performance in terms of processing and printing times, from tests run after version 1.13. Printing was done offline (simply copying a processed file to the printer) to measure real printing speed without regard to speed of processing on the host, since at high resolutions, processing time is the same order of magnitude and thus may become the limiting factor.

The various OutputCodes

I ran several files though Ghostscript and recorded the size of the resulting print code, the processing time, and the printing time, at least for some of the files, always using these options:

gs -sDEVICE=stcolor -sPAPERSIZE=a4 stcolor.ps - < file.ps

(Actually "-sPAPERSIZE=a4" is in my gs_init.ps since I'm a germ.)

"deltarow" is the new encoding principle ("ESC . 3 10 10 1") with Microweave on. It is activated with "-sOutputCode=deltarow".

"Softweave" actually means that nothing else was used: it is the default, and implies that odd v=40/h=10/m=15 mode ("ESC . 1 40 10 15").

"Microweave" means "-dMicroweave", equivalent to "ESC . 1 10 10 1", with full skip optimization and microweave activated.

Finally I wanted to see the plain Kathy Ireland, and used "-sOutputCode=plain", which just replaces runlength encoding (RLE) by no encoding, thus using "ESC . 0 40 10 15". [So sorry ;-) Kathy was still dressed in blue in front of the blue sea on a blue air cushion -- nice to see but hard to dither.]

So here are the results.


File sizes and printing speeds with various weaving methods
    golfer.ps   colorcir.ps   drawing.ps   brief.ps

deltarow   572751/48.180u   643374/41.690u   90142/46.180u/1:50   178563/49.350u/2:22
Softweave   559593/46.810u   669966/44.960u   296168/48.160u/1:30   269808/43.320u/1:55
Microweave   590999/56.060u   754276/42.890u   338885/47.060u/1:50   282314/44.690u/2:22

Kathy Ireland
    kathy.ps

deltarow   3975334/111.940u/5:35
Softweave   3897112/101.940u/3:10
Microweave   4062829/100.990u/3:15
plain/soft   5072255/104.390u/3:05

It may be that I've not chosen the optimal deltarow code, but even if it saves at lot of bytes, printing-speed is not increased.

At least the printer prefers plain Kathy. In other words, sending 1 Megabyte or 20% more data has no impact on printing speed. drawing.ps is an exception to this rule: plain prints slower than RLE.

"Unclever" coding -- especially with deltarow -- can significantly slow down printing. But even if very significant advantages in the size of the code are achieved, "deltarow" is not competitive. colorcir.ps shows savings with deltarow, but printing is a mess.

Printing time related to other options

Full page halftone images printed, unless otherwise noted.


Printing time related to other options
dpi   Print mode   Size KB   Time   Comments

180x180   mono   -/uni   358   1:15    
        -/bi   358   0:45    
        micro/bi   205   0:45   Not weaving
        soft/bi   179   1:25    
    color   -/bi   641   2:45    
        soft/bi   556   1:32    
360x360   mono   -/uni   269   0:50   Monochrome text
        -/bi   269   0:35   Monochrome text
        micro/bi   269   2:25   Monochrome text
        soft/uni   250   3:15   Monochrome text
        soft/bi   250   1:55   Monochrome text
    color   -/bi   346   1:00   Sparse-color page, visible displacements
        micro/bi   346   1:50   Sparse-color page, looks buggy -- printer?
        soft/bi   294   1:30   Sparse-color page, O.K.
        -/bi   2218   2:45   Visible stripes
        micro/bi   5171   3:17    
        soft/bi   3675   3:05    
360x720   mono   soft/bi   2761   5:40    
    color   soft/bi   7789   6:15   Just a small difference!
720x360   color   soft/bi   7182   5:40    
720x720   color   micro/bi   14748   30:26   Actually beyond printer's capabilities
        soft/bi   14407   11:08    

Acknowledgments

This driver was copied from gdevcdj.c (Ghostscript 3.12), which was contributed by George Cameron, Koert Zeilstra, and Eckhard Rueggeberg. Some of the ESC/P2 code was drawn from Richard Brown's gdevescp.c. The POSIX interrupt code (compilation option -DSTC_SIGNAL) is from Frederic Loyer. Several improvements are based on discussions with Brian Converse, Bill Davidson, Gero Guenther, Jason Patterson, ? Rueschstroer, and Steven Singer.

While I wish to thank everyone mentioned above, they are by no means responsible for bugs in the stcolor driver -- just for the features.

Gunther Hess
Richard Wagner Strasse 112
D-47057 Duisburg
Germany
+49 203 376273 telephone (MET evening hours)
<ghess@elmos.de>

uniprint, a flexible unified printer driver

uniprint is a unified parametric driver by Gunther Hess <ghess@elmos.de> for several kinds of printers and devices, including

This driver is intended to become a unified printer driver. If you consider it ugly, please send me your suggestions for improvements. The driver will be updated with them. Thus the full explanation of the driver's name is:

Ugly- -> Updated- -> Unified Printer Driver

But you probably want to know something about the functionality. At the time of this writing uniprint drives:

It can be configured for various other printers without recompilation and offers uncompressed (ugly) Sun rasterfiles as another format, but this format is intended for testing purposes rather than real use. The usage of this driver is quite simple. The typical command line looks like this:

gs @{MODEL}.upp -sOutputFile={printable file} MyFile.ps -c quit

For example, from my Linux box:

gs @stc.upp -sOutputFile=/dev/lp1 tiger.ps -c quit

Unified Printer Parameter files distributed with Ghostscript
Canon BJC 610 (color, rendered)
     bjc610a0.upp    360×360dpi    plain paper, high speed
  bjc610a1.upp   360×360dpi   plain paper
  bjc610a2.upp   360×360dpi   coated paper
  bjc610a3.upp   360×360dpi   transparency film
  bjc610a4.upp   360×360dpi   back print film
  bjc610a5.upp   360×360dpi   fabric sheet
  bjc610a6.upp   360×360dpi   glossy paper
  bjc610a7.upp   360×360dpi   high gloss film
  bjc610a8.upp   360×360dpi   high resolution paper
 
  bjc610b1.upp   720×720dpi   plain paper
  bjc610b2.upp   720×720dpi   coated paper
  bjc610b3.upp   720×720dpi   transparency film
  bjc610b4.upp   720×720dpi   back print film
  bjc610b6.upp   720×720dpi   glossy paper
  bjc610b7.upp   720×720dpi   high-gloss paper
  bjc610b8.upp   720×720dpi   high resolution paper
 
HP Ink-Printers
  cdj550.upp   300×300dpi   32-bit CMYK
  cdj690.upp   300×300dpi   Normal mode
  cdj690ec.upp   300×300dpi   Economy mode
  dnj750c.upp   300×300dpi   Color
  dnj750m.upp   600×600dpi   Monochrome
 
NEC P2X
  necp2x.upp   360×360dpi   8-bit (Floyd-Steinberg)
 
Any Epson Stylus Color
  stcany.upp   360×360dpi   4-bit, PostScript halftoning
  stcany_h.upp   720×720dpi   4-bit, PostScript halftoning
 
Original Epson Stylus and Stylus Pro Color
  stc.upp   360×360dpi   32-bit CMYK, 15-pin
  stc_l.upp   360×360dpi   4-bit, PostScript halftoning, weaved noWeave
  stc_h.upp   720×720dpi   32-bit CMYK, 15-pin Weave
 
Epson Stylus Color II
  stc2.upp   360×360dpi   32-bit CMYK, 20-pin, Epson Stylus Color II(s)
  stc2_h.upp   720×720dpi   32-bit CMYK, 20-pin, Epson Stylus Color II
  stc2s_h.upp   720×720dpi   32-bit CMYK, 20-pin, Epson Stylus Color IIs
 
Epson Stylus Color 200
  stc200.upp   360×720dpi   Plain Paper
 
Epson Stylus Color 500 (good transfer curves for plain paper)
  stc500p.upp   360×360dpi   32-bit CMYK, noWeave, plain paper
  stc500ph.upp   720×720dpi   32-bit CMYK, noWeave, plain paper
 
Epson Stylus Color 600, 32/90-inch weaving
  stc600pl.upp   360×360dpi   32-bit CMYK, 32-pin, plain paper
  stc600p.upp   720×720dpi   32-bit CMYK, 32-pin, plain paper
  stc600ih.upp   1440×720dpi   32-bit CMYK, 30-pin, inkjet paper
 
Epson Stylus Color 640
  stc640p.upp   720×720dpi   plain paper?
 
Epson Stylus Color 800, 64/180-inch weaving
  stc800pl.upp   360×360dpi   32-bit CMYK, 64-pin, plain paper
  stc800p.upp   720×720dpi   32-bit CMYK, 64-pin, plain paper
  stc800ih.upp   1440×720dpi   32-bit CMYK, 62-pin, inkjet paper
  stc1520.upp   1440×720dpi   32-bit CMYK, 62-pin, inkjet paper
 
Sun raster file
  ras1.upp   1-bit   monochrome (Ghostscript)
  ras3.upp   3-bit   RGB (Ghostscript)
  ras4.upp   4-bit   CMYK (Ghostscript)
  ras8m.upp   8-bit   grayscale (Floyd-Steinberg)
  ras24.upp   24-bit   RGB (Floyd-Steinberg)
  ras32.upp   32-bit   CMYK (CMYK-Floyd-Steinberg)

Thanks to Danilo Beuche, Guido Classen, Mark Goldberg and Hans-Heinrich Viehmann for providing the files for the stc200, hp690, stc500 and the stc640.

Please note the following:

The state of this driver

The coding of uniprint was triggered by the requirements of the various Stylus Color models and some personal needs for HP and NEC drivers. Thus the Epson models are well represented among the distributed parameter files. When this driver entered the beta test phase, three other drivers appreared on the scene that could be at least partially integrated into uniprint: cdj850 by Uli Wortmann (available at http://www.erdw.ethz.ch/~bonk/hp850/hp850.html), hpdj by Martin Lottermoser, and bjc610 by Helmut Riegler.

Uli addresses features of the more recent DeskJet models that will not be available in uniprint soon. Martin taught me a lesson on HP-PCL3 headers that will be available in uniprint soon. Helmut in turn followed an almost similar idea, but targetted primarily for printing on Canon printers from the pbmplus library. Starting with version 1.68 of uniprint, BJC support is available. Work on the hpdj integration will start after the update of my website.

Notes on uniprint's background

uniprint is actually an update of stcolor, but much more versatile than its predecessor; stcolor, in its turn, started as a clone of the color DeskJet family of drivers (cdj*). Finally, cdj* can be considered an addition of features to the simpler monochrome drivers of Ghostscript. This addition of features is useful to get an idea of the functionality of uniprint:

Monochrome to advanced color (cdj*):
This adds color mapping and rendering functions to the driver. Error diffusion is especially important for the quality of printing.
HP color to Epson Color (stcolor)
The Epson Stylus Color offered two features simultaneously: it could produce 720×720dpi output and it could soak the paper. In other words, it required more color management features inside the driver. This is still the major conceptual difference in the data generation for HP and Epson printers.
Weaving techniques (stcolor)
Besides the internal color management, the Stylus Color did not provide enough buffer space to operate the printer fast at 720×720dpi. The use of weaving could yield triple the print speed. Weaving, also called interleaving, is present in some monochrome drivers too. The new thing in stcolor was the combination with error diffusion. Unfortunately the weaving was somehow hard-coded, as the problems with the newer members of the Stylus Color family of printers demonstrated.
Generalized output format and weaving (uniprint)
The features mentioned above yield about 90% of stcolor's source code; only 10% is related to the formatting of the output. The idea to make the output format switchable came up soon after completing stcolor, but its final design was triggered by the (personal) necessity to drive a NEC P2X and a Designjet 750c.

Thus uniprint accumulates almost any features that can be found among the other printer drivers, which clearly has some disadvantage in processing speed -- true in particular of version 1.75, since it was targetted for functionality, and several speed-gaining features were (knowingly) omitted.

To summarize and to introduce the terms used in the description of the parameters, the features of uniprint that can be parameterized are:

Godzilla's guide to the creation of Unified Printer Parameter (.upp) files

Here is one of the distributed parameter files (stc_l.upp) with some added comments. Also see the section that describes all uniprint's parameters in brief.

-supModel="Epson Stylus Color I (and PRO Series), 360x360DpI, noWeave"
-sDEVICE=uniprint                    -- Select the driver
-dNOPAUSE                            -- Useful with printers
-dSAFER                              -- Provides some security
-dupColorModel=/DeviceCMYK           -- Selects the color mapping
-dupRendering=/ErrorDiffusion        -- Selects the color rendering
-dupOutputFormat=/EscP2              -- Selects the output format
-r360x360                            -- Adjusts the resolution
-dupMargins="{ 9.0 39.96 9.0 9.0}"   -- Establishes (L/B/R/T margins in points)
-dupComponentBits="{1 1 1 1}"        -- Map: bits per component (default: 8)
-dupWeaveYPasses=4                   -- Weave: Y-passes (default: 1)
-dupOutputPins=15                    -- Format/weave: scans per Command
-dupBeginPageCommand="<              -- Goes to the printer
  1b40   1b40                        -- ESC '@' ESC '@'    -> dual reset
  1b2847 0100 01                     -- ESC '(' 'G' 1 0 1  -> graphics
  1b2869 0100 00                     -- ESC '(' 'i' 1 0 1  -> no HW weave
  1b2855 0100 0A                     -- ESC '(' 'U' 1 0 10 -> 360dpi
  1b5500                             -- ESC 'U'  0         -> bidir print
  1b2843 0200 0000                   -- ESC '(' 'C' 2 0 xx -> page length
  1b2863 0400 0000 0000              -- ESC '(' 'c' 4 0 xxxx -> margins
>"                                   -- as it is, unless:
-dupAdjustPageLengthCommand          -- Adjust page length in BOP requested
-dupAdjustTopMarginCommand           -- Adjust top margin in BOP
-dupAdjustBottomMarginCommand        -- Adjust bottom margin in BOP
-dupEndPageCommand="(\033@\014)"     -- Last (but one) data to the printer
-dupAbortCommand="(\033@\15\12\12\12\12    Printout-Aborted\15\014)"

That's short, and if one removes upWeaveYPasses and upOutputPins it becomes shorter, almost stcany.upp. This miniature size is because I am most familiar with ESC/P2, and was able to add defaults for the omitted parameters. Now a few notes about the parameters used in this example:

If no other weave parameters are given, uniprint computes several defaults which together do no weaving. The /Epson and /EscP2XY formats take care of "upWeaveXPasses" too.

For the ESC/P(2) formats all commands represent binary data, while for the PCL/RTL formatter some of them are formats for fprintf. These strings must explicitly have a trailing "\0'.

I should write more, but the only recommendation is to take a look at the various parameter files. Here are a few more hints.

All parameters in brief

This table gives a brief explanation of every parameter known to uniprint, listing them in alphabetical order. "[ ]" denotes that a parameter is an array, and "(RO)" that it is read-only.


All uniprint parameters
Parameter   Type     Use

upAbortCommand   String   End of page and file on interrupt
upAdjustBottomMarginCommand   Bool   Manipulate bottom margin in upBeginPageCommand
upAdjustMediaSizeCommand   Bool   Manipulate Mediasize [intended]
upAdjustPageLengthCommand   Bool   Manipulate page length in upBeginPageCommand
upAdjustPageWidthCommand   Bool   Manipulate page width in upBeginPageCommand
upAdjustResolutionCommand   Bool   Manipulate resolution
upAdjustTopMarginCommand   Bool   Manipulate top margin in upBeginPageCommand
upBeginJobCommand   String   Begin each output file
upBeginPageCommand   String   Begin each page
upBlackTransfer   Float[ ]   Black transfer (CMYK only!)
upBlueTransfer   Float[ ]   Blue transfer
upColorInfo   Int[ ]   struct gx_device_color_info
upColorModel   Name   Select color mapping
upColorModelInitialized   Bool (RO)   Color mapping OK
upComponentBits   Int[ ]   Bits stored per component
upComponentShift   Int[ ]   Positioning within gx_color_index
upCyanTransfer   Float[ ]   Cyan transfer
upEndJobCommand   String   End each file unless upAbortCommand
upEndPageCommand   String   End each page unless upAbortCommand
upErrorDetected   Bool (RO)   Severe (VM) error, not fully operational
upFSFixedDirection   Bool   Inhbits direction toggling in rendering
upFSProcessWhiteSpace   Bool   Causes white-space rendering
upFSReverseDirection   Bool   Run rendering in reverse (if fixed)
upFSZeroInit   Bool   Non-random rendering initialization
upFormatXabsolute   Bool   Write absolute X coordinates
upFormatYabsolute   Bool   Write absolute Y coordinates
upGreenTransfer   Float[ ]   Green transfer
upMagentaTransfer   Float[ ]   Magenta transfer
upMargins   Float[ ]   L/B/R/T margins in points
upModel   String   Comment string, holds some info
upOutputAborted   Bool (RO)   Caught an interrupt
upOutputBuffers   Int   Number of rendering buffers (2^N)
upOutputComponentOrder   Int[ ]   Order of components when printing
upOutputComponents   Int   Number of written components, not fully operational
upOutputFormat   Name   Select output format
upOutputFormatInitialized   Bool (RO)   Format data OK
upOutputHeight   Int   Output height in pixels
upOutputPins   Int   Number of pins / nozzles per command
upOutputWidth   Int   Output width in pixels
upOutputXOffset   Int   Offset in pixels, if upFormatXabsolute
upOutputXStep   Int   Divisor or multiplier for X coords
upOutputYOffset   Int   Offset in pixels, if upFormatYabsolute
upOutputYStep   Int   Divisor or multiplier for Y coords
upRasterBufferInitialized   Bool (RO)   GS buffer OK
upRedTransfer   Float[ ]   Red transfer
upRendering   Name   Select rendering algorithm
upRenderingInitialized   Bool (RO)   Rendering parameters OK
upSelectComponentCommands   String[ ]   Establish color (output order!)
upSetLineFeedCommand   String   Adjust linefeed (Epson only)
upVersion   String (RO)   Source code version
upWeaveFinalPins   Int[ ]   Number of bottom pins on EOP passes
upWeaveFinalScan   Int   Begin EOP passes (Y-coord)
upWeaveFinalXStarts   Int[ ]   X-pass indices for EOP passes
upWeaveFinalYFeeds   Int[ ]   Y increments for EOP passes
upWeaveInitialPins   Int[ ]   Number of top pins on BOP passes
upWeaveInitialScan   Int   End BOP passes (Y coord)
upWeaveInitialXStarts   Int[ ]   X-pass indices for BOP passes
upWeaveInitialYFeeds   int[ ]   Y increments for BOP passes
upWeavePasses   Int   XPasses × YPasses
upWeaveXPasses   Int   Number of X passes
upWeaveXStarts   Int[ ]   X-pass indices for normal passes
upWeaveYFeeds   Int[ ]   Y increments for normal passes
upWeaveYOffset   Int   Number of blank or incomplete scans at BOP
upWeaveYPasses   Int   Number of X passes
upWhiteTransfer   Float[ ]   White transfer (monochrome devices!)
upWriteComponentCommands   String[ ]   Commands to write each component
upWroteData   Bool (RO)   Something (BeginJob) written to output
upXMoveCommand   String   X positioning command
upXStepCommand   String   Single step to the right
upYFlip   Bool   Flips output along the Y axis
upYMoveCommand   String   Y positioning command
upYStepCommand   String   Single step down
upYellowTransfer   Float[ ]   Yellow transfer

uniprint's Roll of Honor

I should mention all of the people who were involved in stcolor's evolution, but I've decided to start from scratch here for uniprint:

John P. Beale
for testing the stc600 modes
Bill Davidson
who triggered some weaving research and tested stc2s_h
L. Peter Deutsch
who triggered ease of configuration
Mark Goldberg
who prepared the stc500 transfers
Scott F. Johnston and Scott J. Kramer
for testing the stc800 modes
Martin Lottermoser
for his great commented H-P DeskJet driver
Helmut Riegler
for the BJC extension
Hans-Gerd Straeter
for some measured transfer curves and more
Uli Wortmann
for discussions and his cdj850 driver
My family
for tolerating my printer-driver hacking
Gunther Hess
Duesseldorfer Landstr. 16b
D-47249 Duisburg
Germany
+49 203 376273 telephone (MET evening hours)
<ghess@elmos.de>

Sun SPARCprinter

This section was contributed by Martin Schulte.

With a SPARCprinter you always buy software that enables you to do PostScript printing on it. A page image is composed on the host, which sends a bitmap to the SPARCprinter through a special SBUS video interface. So the need for a Ghostscript interface to the SPARCPrinter seems low, but on the other hand, Sun's software prints some PostScript drawings incorrectly: some pages contain a thin vertical line of rubbish, and on some Mathematica drawings the text at the axes isn't rotated. Ghostscript, however, gives the correct results. Moreover, replacing proprietary software should never be a bad idea.

The problem is that there has yet been no effort to make the SPARCPrinter driver behave like a BSD output filter. I made my tests using the script shown here.

Installation

Add sparc.dev to DEVICE_DEVS and compile Ghostscript as described in the documentation on how to build Ghostscript. Afterwards you can use the following script as an example for printing after modifying it with the right pathnames -- including for {GSPATH} the full pathname of the Ghostscript executable:

outcmd1='/vol/local/lib/troff2/psxlate -r'
outcmd2='{GSPATH} -sDEVICE=sparc -sOUTPUTFILE=/dev/lpvi0 -'

if [ $# -eq 0 ]
then
  $outcmd1 | $outcmd2
else
  cat $* | $outcmd1 | $outcmd2
fi

Problems

Since /dev/lpi can be opened only for exclusive use, if another job has it open (engine_ctl_sparc or another Ghostscript are the most likely candidates), Ghostscript stops with "Error: /invalidfileaccess in --.outputpage--"

In case of common printer problems like being out of paper, a warning describing the reason is printed to stdout. The driver tries access again each five seconds. Due to a problem with the device driver (in the kernel) the reason for printer failure isn't always reported correctly to the program. This is the case, for instance, if you open the top cover (error E5 on the printer's display). Look at the display on the printer itself if a "Printer problem with unknown reason" is reported. Fatal errors cause the print job to be terminated.


Apple dot matrix printer

This section was contributed by Mark Wedel <master@cats.ucsc.edu>.

The Apple Dot Matrix Printer (DMP) was a parallel predecessor to the Imagewriter printer. As far as I know, Imagewriter commands are a superset of the Dot Matrix printer's, so the driver should generate output that can be printed on Imagewriters.

To print images, the driver sets the printer for unidirectional printing and 15 characters per inch (cpi), or 120dpi. It sets the line feed to 1/9 inch. When finished, it sets the printer to bidirectional printing, 1/8-inch line feeds, and 12 cpi. There appears to be no way to reset the printer to initial values.

This code does not set for 8-bit characters (which is required). It also assumes that carriage return-newline is needed, and not just carriage return. These are all switch settings on the DMP, and I have configured them for 8-bit data and carriage return exclusively. Ensure that the Unix printer daemon handles 8-bit (binary) data properly; in my SunOS 4.1.1 printcap file the string "ms=pass8,-opost" works fine for this.

Finally, you can search devdemp.c for "Init" and "Reset" to find the strings that initialize the printer and reset things when finished, and change them to meet your needs.


Copyright © 1996, 1997, 1998 Aladdin Enterprises. All rights reserved.

This file is part of Aladdin Ghostscript. See the Aladdin Free Public License (the "License") for full details of the terms of using, copying, modifying, and redistributing Aladdin Ghostscript.

Ghostscript version 6.0, 3 February 2000