Re: [Gimp-user] Epson <esc>i print format (Gutenprint question)

[Gary Aitken <gimp dreamchaser org>]

On 3/1/22 1:34 PM, Liam R E Quin wrote:
> On Tue, 2022-03-01 at 08:59 -0700, Gary Aitken wrote:
> > I have a simple image with one straight line of a single color.
> > Using the gutenprint dialog, I can print that file.
> > If I do a "reverse translation" of the raw file, there is one escp2
> > command
> > in it to print the line, shown below with some notes:
>
> Hello! I'm afraid i'm a little lost here sir - which raw file exactly?
> The stream being sent to the printer?  What problem are you trying to
> solve exactly?  Why not look at the source code to the driver and/or
> the printer specification?

Yeah, I'm probably way more lost than you are...

The file is one generated by gutenprint and sent using the command
"/usr/local/bin/lp -s -d 'printer_name' -oraw" to the cups print system.
So yes, the stream being sent to the printer.

I have been looking at the source, the (outdated) gutenprint docs, and the
(outdated) Epson ESCP2 documentation.  The escp2 documentation discusses
the encoding with examples in terms of full-byte characters, which doesn't
seem like it translates obviously into 2-bit nozzles; unless you assume you
can't treat the input stream as 2 bit chunks.

I need to generate a number of specific output data streams to the printer;
generally regular, single-ink outputs.  I can't get the gutenprint plugin to
do it because it always dithers the output; I don't see any way to turn the
dithering off.  I'm not worried about banding.  If I can understand the
output encoding, I can encode a replacement segment to patch into the output
stream.  Not eloquent, but a means of testing to continue with a project.

FWIW, the hex dump in the original post is from a single pixel pure cyan line
360 pixels long, printed with print quality=manual, media=photo paper, 360x360
resolution, unidirectional, interleave off.

My attempt on the provided data follows:

If I start with the 0xde:

00000c0 691b 0112 6802 0101 de00 1200 9a05 6959
        esc i 12 01 02 0168 0001  (print command)
        count is 0x168 = 360  lines is 0x0001
  data starts at 00000c9      de 1200 9a05 6959
  0xde = 222 (negative byte) => 256-222 = 34; + 1 = 35 (repeat count)
    next byte = 00 => 35 * {00 00 00 00} => 160 pixels empty space
  0x12 = positive count of 18; + 1 = 19 data bytes following
    gets us to 00000df
00000d0 5999 a565 5999 6566 5996 9695 655a fd56
                                             fd
  0xfd=253 (neg) => 256-253 = 3; + 1 = repeat 4
    next byte (00000e0) = 0x66 => 4 * {01 10 01 10}
00000e0 1f66 9a59 6656 6566 5996 9665 9659 6666
  00000e1 = 0x1f = 31; + 1 = 32 data bytes following
    gets us to 0000102
00000f0 6559 9999 9565 6695 9965 a665 6666 6969
0000100 5566 95fe 9919 6596 5996 5696 9666 665a
  0000102 = 0xfe = 254 (neg) => 256-254 = 2; + 1 = repeat 3
     next byte 0x95 => 3 * {10 01 01 01}
     next byte (0000104) 0x19 = 25; + 1 => 26 data bytes following
       gets us to 000011f
0000110 5956 6669 0456 1044 0041 4110 0040 8140
  000011f = 0x81 = 129 (neg) => 256-129 = 127; + 1 = repeat 128
      next byte (0000120) 0x00 => 128 * {00 00 00 00}
        gets us to 0000121
0000120 9000 0d00 1b0c 1b40 5228 0008 5200 4d45
  0000121 = 0x90 = 144 (neg) => 256-144 = 112; + 1 => repeat 113
     next byte (0000122) 0x00 => 113 * {00 00 00 00}
       gets us to 0000123

That uses up 360 bytes of output data, which matches the count.
  (35 + 19 + 4 + 32 + 3 + 26 + 128 + 113 = 360)
Unfortunately, we're left with 1 byte, 0x0d, left-over.
The next command in the print stream is actually the 0x0c (FF) at 0000124.

Any insights would be much appreciated,

Gary