THIS FILE HAS BEEN SNIPPED TO SHOW ONLY EPSON COLOR STYLUS INFO - MH (ORIGINAL IN /USR/DOC/GHOSTSCRIPT) This file, devices.txt, gives more detailed documentation about certain specific devices for which Ghostscript can produce output. For an overview of Ghostscript and a list of the documentation files, see README. ### ------------------ The Epson Stylus Color printer ------------------ ### /* Epson Stylus-Color Driver, contributed by Gunther Hess (address: see below) I N T R O D U C T I O N ======================= This documentation accompanies version 1.90 of the stcolor-driver. Compared to version 1.21 (gs3.53) there are just a few, but somehow important chages: - Default: noWeave escpBand=1 (-> default works with all known models) - added Parameter "Softweave" (useful only with Original STC and PRO-Series) - added Compile-Option (-DSTC_SIGNAL) to catch interrupts during printing (thanks to Frederic Loyer) - compatibility with ansi2knr - compatibility with 64Bit Processors - clarification of usage with Pro-XL and Stylus Color II A Note on the Version-Numbering: Version 1.xx comes to it's end. Any 1.xx > 1.90 will have only Bug-Fixes. Maybe that Version 2.xx comes to life, if this is the case it will include full support of the newer models. U S A G E ========= This driver is selected with "-sDEVICE=stcolor" and produces 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 the monochrome-versions of this printer. This can be achieved either via command-line options or via ghostscript-input. For convienience a Postscript-File is supplied, that can be used as initial inputfile. Thus, assumed that ghostscript is invoked via "gs" on your computer, try the following command: gs -sDEVICE=stcolor -rXDPIxYDPI stcolor.ps ... (e.g.: your input-files) were XDPI is one of 180/360/720 and YDPI is one of (90/)180/360/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 ghostscript input-directory. Thus if ghostscript is part of your printer-spooler, you can insert (stcolor.ps) findlibfile { pop run } if pop to the files you want to run through the improved algorithms and you may want to adapt this file to your specific needs. The methods and options for this are described here, but this description is restricted to the gs-options, while their manipulation at the Postscript-level is documented in "language.txt" and in the mentioned "stcolor.ps". Next thing is 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 printers "microweave"-feature. -dnoWeave - disable any Weaving, overrides -dMicroweave -dSoftweave - enable internal weaving of the driver. * Weave-Note: Softweave works *ONLY* with the original Stylus-Color * and the PRO-Series. -sDithering="name" - select another dithering-algorithm, available are: "gscmyk" : fast color-output, with CMYK-ProcessColorModel [D] "gsmono" : fast black & white output "gsrgb" : fast color-output, with RGB-ProcessColorModel "fsmono" : Floyd-Steinberg, Monochrome "fsrgb" : Floyd-Steinberg, with RGB-ProcessColorModel (Almost identical to cdj550/mjcxxx-Algorithm) "fsx4" : Floyd-Steinberg, with CMYK-ProcessColorModel (shares code with fsmono & fsrgb, but is algorithmically really bad) "fscmyk" : Floyd-Steinberg, with CMYK-ProcessColorModel and proper modifications for CMYK "hscmyk" : modified Floyd-Steinberg with CMYK-Model ("hs" stands for "hess" nor for "high speed", but the major difference to "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, when restricting to 24 Bits, rather than the default of 30. -dFlag0 - causes some algorithms to select a uniform initialisation rather than a set of random-values. May yield "sharper" image-impression at the cost of "dithering-atrefacts". (applies to hscmyk and all fs-modi, except for fs2, which always uses a constant initialization.) -dFlag1 ... -dFlag4 - available to future algorithms. -dColorAdjustMatrix={3/9/16 x float}' - This is a Matrix to adjust the colors. Values should be between -1.0 and 1.0, and the number of values depend on the colormodel used by the selected algorithm. In RGB- and CMYK-modi a matrix with 1.0 on the diagonal produces no transformation. (I could not identify a similar feature at the language-level, so this option was implemented, it is really required, but I don't know reasonable values yet.) -dCtransfer='{float float ...}', -dMtransfer=..., -dY..., -dK... or -dRtransfer='{float float ...}', -dG..., -dB... or -dKtransfer='{float float ...}' - which is used, depends on the algorithm, which maybe either either CMYK, RGB or monochrome. The values are arrays of floats in the range from 0 to 1.0, which represent 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. - this are again arrays between 0.0 and 1.0, and they control the internal coding of the color-values. Clever usage of this arrays may yield further enhancements, but 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= - can be either "plain", "runlength" or "deltarow" and changes the ESC/P2 (TM) coding-technique used by the driver. The default is to use the runlength-encoding. "plain" selects uncompressed encoding and yields enormeous amounts of data to generated. -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= - Number of Pixels Printed in each scan-Line. (Useful when tuning Margins only, se below) -descp_Height= - Length of the entire Page in Pixels (Parameter of "ESC(C" in default initialization) -descp_Top= - Top-Margin in scanlines. (1st Parameter of "ESC(c" in default initialization) -descp_Bottom= - Bottom-Margin in scanlines. (2nd Parameter of "ESC(c" in default initialization) -sescp_Init="..." - Override for the initialization-sequence. (Must set Graphics-Mode-1 & Units) -sescp_Release="..." - Overrides the release-sequence. (ESC @ FF by default) Valid Resolutions: any, ESC/P2 allows in theory, but only the following are known to work with most printers: -r360x360 (Default) -r720x720 (not on STC-IIs ? and st800) Valid Option Combinations: (Stylus I & PRO-Series only) escp_Band ?Weave escp_Band/#Passes 180x 90 15 no-Weave 180x180 1 , 8, 24 no/u-Weave 15/2 sWeave 180x360 15/4 sWeave 180x720 15/8 sWeave 360x 90 15 no-Weave 360x180 1, 8, 24 no/u-Weave 15/2 sWeave 360x360 1, 8, 24 no/u-Weave 15/4 sWeave 360x720 15/8 sWeave 720x 90 15 no-Weave 720x180 15/2 sWeave 720x360 15/4 sWeave 720x720 1 no/u-Weave 15/8 sWeave ************************************************************************* ************************************************************************* ** ** ** BEWARE: There are only few validity-checks for parameters. A good ** ** example is "escp_Band": if you set this, the driver tries ** ** to use your value, even if this value is not supported by ** ** the printer: ** ** ** ** YOU ASKED FOR IT, AND YOU GOT IT! ** ** ** ************************************************************************* ************************************************************************* A P P L I C A T I O N - N O T E ================================ 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 50 Times, I prepared a STC-FAQ-Collection. I am currently unable offer this FAQ on the net. But thanks to Bill Davidson it is available as: http://www.isisnet.com/bdavidson/gs_stc.FAQ.html And here it comes (as plain text): VERSION: This FAQ refers to ghostscript > 3.50 with stcolor > 1.20. The former release (ghostscript-3.33/stcolor-1.12) used different parameters and had some severe bugs. This FAQ is itself version 1.3. TOPIC: Pro XL? Yes, this driver supports the A3-Size Printer. Simply set the required pagesize and margins. A simple way to do this, is to specify the parameter "-sPAPERSIZE=a3" on the commandline or to include the procedure-call "a3" in the postscript-Prolog section. If you want to optimize the printable area and/or set the proper Margins, see topic Margins, PageSize. TOPIC: Margins, PageSize Different than other drivers, i refuse to add code to the stcolor-driver, that tries to guess the proper margins or pagesize. This is due to the fact, that i found that such guessing is usually wrong and needs correction either in the source or the parameters. The following code can be inserted to "stcolor.ps" after the line: mark % prepare stack for "putdeviceprops" And this is the new code: /.HWMargins [9.0 39.96 12.6 9.0] % Left, Bottom, Right, Top (1/72") /PageSize [597.6 842.4] % Paper, including Marings (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 for ".HWMargins" and "PageSize" to match your needs. The given Values are the defaults from the driver, when compiled with "-DA4" set. This Option -or it's omission- may cause trouble: The Stylus Color can print exactly 8" or 2880Pixel@360DpI. The remaining paper is the margin, where the left margin varies only slightly with the papersize, while the right margin ist significantly increased for wider paper, such as letter. -> If you are using stcolor > 1.20, compiled without "-DA4", on european paper, then the Default-Margin is too large. You need to add the proper ".HWMargins" to the commandline or stolor.ps TOPIC: Stylus Color II / IIs and 1500. First the good news: The driver can print on the Stylus Color II. And the bad ones: - According to Epson-Support the driver "abuses" the color-capabilities. (See topic "Future Plans" for details.) - You need some parameters on the command-line (or in stcolor.ps). - I doubted that it would be usable with the Stylus Color IIs. *BUT* it is usable and suffers from the mixing-Problems!!. To make thinks work, you *MUST* disable the drivers internal weaving ("Softweave"). This can be done in two ways: gs .... -dMicroweave .... or gs ... -dnoWeave -descp_Band=1 .... [1.90 fixes this "bug" due to a changed default-behaviour] I experienced significantly increased printing speed with the second variant on the old Stylus Color, when printing mostly monochrome data. TOPIC: Future Plans Actually i thought, that the driver is finished by now, but an answer from Epson triggered future development. This was the answer from Epson-Support: To: Klaus-Gunther Hess Subject: Help: Need Programming Info for Stylus-(Color)-Printers The differentiation is necessary, as the printers produce the graphics differently. To wit: CMY Class - ( Stylus Color IIs ) The Stylus Color IIs prints color graphics with the three different color inks (cyan, magenta, and yellow). Also, black is printed using composit black (mixture of CMY). For high quality laser like black, a separate black ink cartridge should be used. CMY + K Class - ( Stylus Color II ) This printer has both a CMY and a black ink (K) cartridge installed at the same time. However, due to the nature of the black ink it can not be mixed or overlaid with the color inks. Therefore, when black is needed, composite black is used. If the image calls for pure black (e.g., text), the black cartridge is used. CMYK Class - ( Stylus Color, Stylus Pro and Pro XL ) These printers have a mixable black (K) ink. This ink is compatible with the CMY inks and will not bleed when combined or printed next to the CMY inks. Bruce U. The Epson Connection Thus I am working on a version, that supports CMY and CMY + K dithering. Actually there are also some new (*undocumented*) instructions used by the windows-driver in conjunction withe the Stylus Color II/IIs, that raises the need for some more "escp_*" Parameters. A C K N O W L E D G E M E N T S =============================== This driver was "copied" from gdevcdj.c (ghostscript-3.12), which was contributed by: George Cameron - g.cameron@biomed.abdn.ac.ukis Koert Zeilstra - koert@zen.cais.com Eckhard Rueggeberg - eckhard@ts.go.dlr.de Some of the ESC/P2-code was drawn from gdevescp.c, contributed by Richard Brown - rab@eos.ncsu.edu The POSIX-Interrupt-Code is from (Compile-Time-Option -DSTC_SIGNAL) Frederic Loyer - loyer@ensta.fr And several improvements are based on discussions with Brian Converse - BCONVERSE@ids.net Bill Davidson - bdavidson@ra.isisnet.com Gero Guenther - gero@cs.tu-berlin.de Jason Patterson - jason@reflections.com.au ? Rueschstroer - rue@ibe.med.uni-muenchen.de Steven Singer - S.Singer@ph.surrey.ac.uk While I wish to thank all this people mentioned above, they are by no means responsible for bugs in the stcolor-driver - just for the features. Duisburg 8-May-1996, Gunther Hess up to sometime E-Mail: gunther@elmos.de After that time, one should use snail-mail or phone: Gunther Hess phone: ++49 203 376273 Richard Wagner Strasse 112 D-47057 Duisburg Germany R E C O M M E N D A T I O N S ============================= The next section is a contribution from Jason Patterson 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* it would not allow the selection of "gscmyk". So here comes a very truncated version of Jasons text: COLOR DITHERING EXPERIMENTS with gdevstc-1.21 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's a bit of feedback about the EPSON Stylus Color driver's different dithering methods, based on a little experiment using 4 good quality scanned images of quite varied nature. Here is a summary of the results of the four experiments... 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 then you'd expect that 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 (which were done with the MS-Windows driver). Overall Visual Quality (out of ten): gsmono |********* fsmono |***************** | gscmyk |******** gsrgb |********* fs2 |**************** fsrgb |***************** hscmyk |****************** fscmyk |****************** +--------------------- 0 1 2 3 4 5 6 7 8 9 10 best-to-worst order: color: fscmyk hscmyk fsrgb fs2 gsrgb gscmyk mono: fsmono gsmono SANITY NOTE: The above results are only from *four* images, a total of 24 printouts (8 on 720dpi paper, 16 on plain paper). Your results will almost certainly vary, and your standards might not be the same as mine, so use these results as a *guide* only, not as a formal evaluation. C O L O R - T R A N S F O R M A T I O N ======================================= *NOTE*: Things are changing with version gdevstc > 2.00! 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. This is the result of 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, that provides 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 influences directly 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/24/32Bit | => | 1/3/4x Values | | 1/3/4x16Bit Values | | for all components | | (arbitrary type) | +---------------------+ +---------------------+ +------------------+ Due to the limitations on raster-storage, information is lost in the first transformation step, except for the 16Bit Monochrome-Mode. So any color adjustment should take place before this step and this is where the optional ColorAdjustMatrix works. The first transformation-step is called "coding" and is controlled by the ?coding-Arrays. The Decoding-process expands the range of values pontentially to a larger range than that provided by the initial ghostscript color-model. It is therefore a reasonable place to make device- and/or algorithm-specific adjustments. This is the place 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 internaly algorithm-specific array-access. If 8Bits are stored per color-component and if the algorithm uses bytes too, the second transformation is included within the first, what saves significant computation-time when printing the data. ColorAdjustMatrix ----------------- The driver supports different "ProcessColorModel"-Values, which raises the need for different color-adjustments. In the following "CAM" stands for ColorAdjustMatrix: DeviceGray: (3 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 in drivers.txt, the latter should never happen. DeviceRGB: (9 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 uses always four inks, thus a special treatment of black is provided. Algorithms may take special action, if r==g==b. Maybe that in future versions Kcoding & Ktransfer become active in RGB-Mode. DeviceCMYK: (16 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, that delivers black under certain circumstances as (1,1,1,0). Normally, when no special "Black Seperation" 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, thus during mapping black-seperartion 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 seperated and removed Black. Raising the CMY-Coefficients while lowering the K-coefficients reduces black and intensifies color. But be careful, even low 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 - Black-Separation in CMYK-Mode RGB/CMYK-coding & -transfer and BitsPerPixel -------------------------------------------- This two (groups) of parameters are arrays of floatingpoint-numbers in the range 0.0 to 1.0. They control the truncation to the desired number of bits stored in the raster-memory (BitsPerPixel) and the ink-density. The "truncation" may become a nonlinear-function, if any of the ?coding-arrays are set. Assume the following Ghostscript invocation: gs -sDEVICE=stcolor -sDithering=fscmyk -dBitsPerPixel=16 \ -dMcoding='{ 0.0 0.09 0.9 1.0 }' \ -dYtransfer='{ 0.0 0.09 0.9 1.0 }' \ -dKcoding='{ 0.0 0.09 0.9 1.0 }' -dKtransfer='{ 0.0 0.09 0.9 1.0 }' \ We may have ?coding and/or ?transfer, thus four combinations are possible and this four combinations appear in the given example. The resulting mapping is given in the following tables, where except for the internal Indices (4 Components * 4 Bits = 16 BitsPerPixel), all values are normalized to the Range 0-1. The actual range is 0 to 65535 for the ghostscript-color and 0 to 16777215 (2^24-1) 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", what 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 16 component-indices. If no coding-array is given, this is accomplished by a division with 4096 -equivalent to a right-shift by 12 Bits-. The final ink-density resides in the given interval and moves form the left to the right side from 0 to 15. In the Magenta-case, 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, what is exactly the same functionaltity, that Postscripts "(color)transfer"-function provides. While in the case of Yellow, the intervals match the intervals used with Cyan, the inetervals used for Black match the Magenta-Intervals, but watch the corespondence between the CI/15-values and the Ink-Density for Black: This is a linear distribution in the Ink-domian. Not a bad idea, I think. Consider the fs2-algorithm: It uses values in the range 0-255 (Bytes). If any transfer-array would be supplied alone, some of the 256 possible values would never be used and others will be used for adjacent intervals several times. Establishing an identical coding-array solves this problem, so that the full potential of the algorithm is utilized. Another useful feature of the coding-arrays is, that they are internally normalized to the 0-1 Range. In the 720x720Dpi-Mode the transfer-arrays in stcolor.ps limit the Dot-Density to about 50%, thus this arrays end at 0.5 (respectively start at 0.5 in the RGB-case). Due to the automatic normalization this arrays can be used as coding-arrays too. But of course in the fs2-case mentioned above, values from 0-127 will never be deliverd to the algorithm, while values 128-255 are delivered for adjacent intervals. To clearify the intended use of the three parameters/parameter-groups the following statements should be kept in mind: - ColorAdjustMatrix is never used, when transferring gray-values. This restricts it to what the name says: Adjustment of Colors e.g. the correction for miscolored ink. Do not use it for staturation or brightness-control. - ?transfer-arrays control the values delivered to the driver, which in turn controls the ink-quantity. This arrays should be used for control of saturation and brightness. Maybe that a Postscript-Header for the manipulation of brightness and so on will be provided with future versions. In general this arrays are identical for all inks. If they differ they provide a simpler scheme for color-correction, which is not necessarily faster than the ColorAdjustMatrix. - ?coding-arrays control the color-value-intervals mapped to the internal color-indices. P R I N T - M O D I =================== The parameters "Unidirectional", "Microweave", "noWeave", "OutputCode", "Model" and the given resolution provide control over the data generated for the printer. Unidirectional -------------- Simply toggles the unidirectional-mode of the printer. Setting "Unidirectional" definitly decreases printing-speed, but may increase the quality. I use this for printing tranparencies, where fast head-movement could smear the ink. Microweave, noWeave and OutputCode=deltarow ------------------------------------------- The first are two Booleans, what immediatly tells, that 4 combinations are possible. Actually only three exist (if you don't count for deltarow): 1. Softweave 2. Microweave 3. noWeave First and second are functionally identical, their difference is that either the driver or the printer does the job. So the question What is weaving ? arises. The Epson Stylus Color has a Head-Assembly that contains two physically identifiable Heads. One for Black and one for Cyan/Magenta/Yellow. This makes 4 logical Heads, one for each color-component. Each of this four heads has several jets at some Y-distance, so several horizontal lines can be printed during one pass of the heads. From the experience I think there are 15 Jets per color spaced at 1/90". So the question arises, how to print at a Y-Resolution of 360Dpi with this 90DpI-Jets. Simply by divison, one gets 360/90 = 4, what tells us, that 4 Passes of the head-assembly are required to achieve a Y-resolution of 360DpI. Weaving is just the scheme how the 15 jets are utilized to print adjacent horizontal rows: Weaving noWeave Pass: 1 2 3 4 1 2 3 4 0/360" jet0 - - - jet0 - - - 1/360" - jet1 - - - jet0 - - 2/360" - - jet2 - - - jet0 - 3/360" - - - jet3 - - - jet0 4/360" jet1 - - - jet1 - - - 5/360" - jet2 - - - jet1 - - 6/360" - - jet3 - - - jet1 - .... Now let us 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 the some averaging takes place. Without weaving adjacent rows are printed by the same jet and this makes the dot-diameter-deviations visible as 1/90"-stripes in the printout. In Softweave-Mode (the default) the driver sends the data properly arranged to the printer, while in Microweave-Mode the printer does the same job. But in general the host-processor is much faster than the printers processor and thus it is advantageous to let the host do this job. In addition to that, for 720DpI 8 Passes are required and the amount of buffer-space required to buffer the data for the passes is far beyond the printers memory. SoftWeave requires an odd value of "escp_Band", the Stylus Color provides 15 for that. "OutputCode" controls the encoding used. In the basic modi, the choice consists of "plain" and "runlength". The computation of runlength-encoded data does not take much time, at least less than the datatranfer 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, since there were not potential advantages found, "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 increased 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 ommits some parts of the initialization-sequence, which are not compatible with the given printer model. Currently only "st800" is supported besides the default (stcolor). BEWARE: BUGS & PITFALLS ======================= * The given ?coding and ?transfer arrays should be strictly monotonic. * It is impossible to change WHITE: that's your paper. Thus R/G/B-transfer should end at 1.0 and C/M/Y/K-transfer should start at 0.0. * Usually 8Bits per component yields fastest operation. * The ColorAdjustMatrix is not used in the reverse-transformation, which is used, when Gostscript does the dithering (gs*-Modi). Expect funny results. * If BitsPerPixel is less than 6, the entire coding/transfer-process does not work. This is always true for the gs*-modi and becomes true for the other modi, if BitsPerPixel is forced to low values. * 720x720Dpi-Printing should never select the gs-modi and should always use stcolor.ps. (I prefer 360x720) T E S T S (version 1.13 and above) ================================== This section should give an overview over the performance in terms of processing- & printing-time. Printing is done offline (via cp-instruction) to measure real printing-speed, since at high-resolutions processing-time is in 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 code, the processing time and the printing-time, at least for some of the files. Always the following options were used: "-sDEVICE=stcolor -sPAPERSIZE=a4 stcolor.ps - < file.ps" (Actually "-sPAPERSIZE=a4" is in my gs_init.ps since I'm a germ.) "Softweave" means actually, 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" is just "-dMicroweave", which is equivalent to "ESC . 1 10 10 1", with full skip-optimization and microweave-activated. "deltarow" is the new encoding principle ("ESC . 3 10 10 1") with Microweave on. It is activated with "-sOutputCode=deltarow". Finally I wanted to see the plain Kathy Ireland and used "-sOutputCode=plain", which is just replacing RLE by no encoding, thus "ESC . 0 40 10 15" is used then. [So sorry ;-) Kathy was still blue dressed in front of the blue sea on a blue air-cushion - nice to see but hard to dither] So here are the results: 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.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 Evaluation: A.) Might be, that I've not choosen the optimal deltarow-code, but even if it saves at lot of bytes, printing-speed is not increased. B.) At least the printer prefers plain-kathy. In other words: Sending a 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] C.) But "unclever" coding -especially with deltarow- can significantly slows down printing. But even if very significant advantages in the size of the code ar achieved, "deltarow" is not competitive. [colorcir.ps shows savings in deltarow, but printing is a mess.] Printing-Time related to other options -------------------------------------- Full page halftone images printed, unless otherwise noted. DpI print-mode Size Time comments 180x180 mono -/uni 358KB 1:15 -/bi 358KB 0:45 micro/bi 205KB 0:45 (not weaving) soft/bi 179KB 1:25 color -/bi 641KB 2:45 soft/bi 556KB 1:32 360x360 mono -/uni 269KB 0:50 (b/w Text) -/bi 269KB 0:35 (b/w Text) micro/bi 269KB 2:25 (b/w Text) soft/uni 250KB 3:15 (b/w Text) soft/bi 250KB 1:55 (b/w Text) color -/bi 346KB 1:00 (sparse color-page, visible displacements) micro/bi 346KB 1:50 (sparse color-page, looks buggy - printer?) soft/bi 294KB 1:30 (sparse color-page, O.K.) -/bi 2218KB 2:45 (visible stripes) micro/bi 5171KB 3:17 soft/bi 3675KB 3:05 360x720 mono soft/bi 2761KB 5:40 color soft/bi 7789KB 6:15 (just a small difference!) 720x360 color soft/bi 7182KB 5:40 720x720 color micro/bi 14748KB 30:26 (actually beyond printers capabilities) soft/bi 14407KB 11:08 ### ------------------------------ End --------------------------------- ###