1 files changed, 152 insertions, 0 deletions
diff --git a/doc/manual-html/gimpprint_27.html b/doc/manual-html/gimpprint_27.html
new file mode 100644
index 0000000..dbd76d4
--- /dev/null
+++ b/doc/manual-html/gimpprint_27.html
@@ -0,0 +1,152 @@
+<HTML>
+<HEAD>
+<!-- This HTML file has been created by texi2html 1.51
+     from .././gimpprint.texi on 11 June 2004 -->
+
+<TITLE>GIMP-Print - Weaving introduction</TITLE>
+</HEAD>
+<BODY>
+Go to the <A HREF="gimpprint_1.html">first</A>, <A HREF="gimpprint_26.html">previous</A>, <A HREF="gimpprint_28.html">next</A>, <A HREF="gimpprint_47.html">last</A> section, <A HREF="gimpprint_toc.html">table of contents</A>.
+<P><HR><P>
+
+
+<H2><A NAME="SEC42" HREF="gimpprint_toc.html#TOC42">B.1  Introduction</A></H2>
+
+<P>
+The Epson Stylus Color/Photo printers don't have memory to print using
+all of the nozzles in the print head.  For example, the Stylus Photo
+700/EX has 32 nozzles.  At 720 dpi, with an 8" wide image, a single line
+requires @math{(8 * 720 * 6 / 8)} bytes, or 4320 bytes (because the
+Stylus Photo printers have 6 ink colors).  To use 32 nozzles per color
+would require 138240 bytes.  It's actually worse than that, though,
+because the nozzles are spaced 8 rows apart.  Therefore, in order to
+store enough data to permit sending the page as a simple raster, the
+printer would require enough memory to store 256 rows, or 1105920 bytes.
+Considering that the Photo EX can print 11" wide, we're looking at more
+like 1.5 MB.  In fact, these printers are capable of 1440 dpi horizontal
+resolution.  This would require 3 MB.  The printers actually have
+64K-256K.
+
+</P>
+<P>
+With the newer (740/750 and later) printers it's even worse, since these
+printers support multiple dot sizes; of course, the even newer
+2880x720 printers don't help either.
+
+</P>
+<P>
+Older Epson printers had a mode called <STRONG>MicroWeave</STRONG> (tm).  In this
+mode, the host fed the printer individual rows of dots, and the printer
+bundled them up and sent them to the print head in the correct order to
+achieve high quality.  This MicroWeave mode still works in new printers,
+but in some cases the implementation is very minimal: the printer uses
+exactly one nozzle of each color (the first one).  This makes printing
+extremely slow (more than 30 minutes for one 8.5x11" page), although the
+quality is extremely high with no visible banding whatsoever.  It's not
+good for the print head, though, since no ink is flowing through the
+other nozzles.  This leads to drying of ink and possible permanent
+damage to the print head.
+
+</P>
+<P>
+By the way, although the Epson manual says that microweave mode should be
+used at 720 dpi, 360 dpi continues to work in much the same way.  At 360
+dpi, data is fed to the printer one row at a time on all Epson printers.
+The pattern that the printer uses to print is very prone to banding.
+However, 360 dpi is inherently a low quality mode; if you're using it,
+presumably you don't much care about quality.  It is possible to do
+microweave at 360 DPI, with significantly improved quality.
+
+</P>
+<P>
+Except for the Stylus Pro printers (5000, 5500, 7000, 7500, 9000,
+9500, and when it's released the 10000), which can do microweave at
+any resolution, printers from roughly the Stylus Color 600 and later
+do not have the capability to do MicroWeave correctly in many cases
+(some printers can do MicroWeave correctly at 720 DPI).  Instead, the
+host must arrange the output in the order that it will be sent to the
+print head.  This is a very complex process; the jets in the print
+head are spaced more than one row (1/720") apart, so we can't simply
+send consecutive rows of dots to the printer.  Instead, we have to
+pass e. g. the first, ninth, 17th, 25th... rows in order for them to
+print in the correct position on the paper.  This interleaving process
+is called "soft" weaving.
+
+</P>
+<P>
+This decision was probably made to save money on memory in the
+printer.  It certainly makes the driver code far more complicated than
+it would be if the printer could arrange the output.  Is that a bad
+thing?  Usually this takes far less CPU time than the dithering
+process, and it does allow us more control over the printing process,
+e.g. to reduce banding.  Conceivably, we could even use this ability
+to map out bad jets.
+
+</P>
+<P>
+Interestingly, apparently the Windows (and presumably Macintosh) drivers
+for most or all Epson printers still list a "microweave" mode.
+Experiments have demonstrated that this does not in fact use the
+"microweave" mode of the printer.  Possibly it does nothing, or it
+uses a different weave pattern from what the non-"microweave" mode
+does.  This is unnecessarily confusing, at least for people who write
+drivers who try to explain them to people who don't.
+
+</P>
+<P>
+What makes this interesting is that there are many different ways of of
+accomplishing this goal.  The naive way would be to divide the image up
+into groups of 256 rows (for a printer with 32 jets and a separation of
+8 rows), and print all the mod8=0 rows in the first pass, mod8=1 rows in
+the second, and so forth.  The problem with this approach is that the
+individual ink jets are not perfectly uniform; some emit slightly bigger
+or smaller drops than others.  Since each group of 8 adjacent rows is
+printed with the same nozzle, that means that there will be distinct
+streaks of lighter and darker bands within the image (8 rows is 1/90",
+which is visible; 1/720" is not).  Possibly worse is that these patterns
+will repeat every 256 rows.  This creates banding patterns that are
+about 1/3" wide.
+
+</P>
+<P>
+So we have to do something to break up this patterning.
+
+</P>
+<P>
+Epson does not publish the weaving algorithms that they use in their
+bundled drivers.  Indeed, their developer web site
+(http://www.ercipd.com/isv/edr_docs.htm) does not even describe how to
+do this weaving at all; it says that the only way to achieve 720 dpi is
+to use MicroWeave.  It does note (correctly) that 1440 dpi horizontal
+can only be achieved by the driver (i. e. in software).  The manual
+actually makes it fairly clear how to do this (it requires two passes
+with horizontal head movement between passes), and it is presumably
+possible to do this with MicroWeave.
+
+</P>
+<P>
+The information about how to do this is apparently available under
+non-disclosure agreement (NDA).  It's actually easy enough to reverse
+engineer what's inside a print file with a simple Perl script, which is
+supplied with the Gimp-Print distribution as tests/parse-escp2.  In any
+event, we weren't particularly interested in the weaving patterns Epson
+used.  There are many factors that go into choosing a good weaving
+pattern; we're learning them as we go along.  Issues such as drying time
+(giving the ink a few seconds more or less to dry can have highly
+visible effects) affect the quality of the output.
+
+</P>
+<P>
+The Uniprint GhostScript driver has been able to do weaving for a long
+time.  It uses patterns that must be specified for each choice of
+resolution and printer.  We preferred an algorithmic approach that
+computes a weave pattern for any given choice of inputs.  This
+obviously requires extensive testing; we developed a test suite
+specifically for this purpose.
+
+</P>
+
+<P><HR><P>
+Go to the <A HREF="gimpprint_1.html">first</A>, <A HREF="gimpprint_26.html">previous</A>, <A HREF="gimpprint_28.html">next</A>, <A HREF="gimpprint_47.html">last</A> section, <A HREF="gimpprint_toc.html">table of contents</A>.
+</BODY>
+</HTML>