Re: [Gimp-print-devel] The Truth Behind ESC ( D

[<sh...@al...>]

> But this still doesn't entirely add up.  The vertical spacing is a
> hardware matter -- the jets are exactly such a distance a part, and no
> amount of programming will change that.

You are assuming softweave mode.  But what about in microweave?  Vertical
resolution is determined solely by paper advances.  I would imagine that
they have some sort of stepper motor that does the advancing, rather than
a continuous motor with a timed pulse, so you couldn't support arbitrary
resolutions, but, probably quite a few more than are currently supported.

> Unless by programming a
> multiple of that you can turn off some of the jets?  But to what end?

I don't know.  With RLE, you can zero out the line for a nozzle in just a
few bytes, so, turning off a nozzle is cheap in terms of the amount of
data you need to send over the bus, but, what does the printer do with
that data when it is received?  Is it kept RLE and decoded on the fly
as the head moves?  Or is it decoded into a RAM buffer before a pass?
I suspect the latter.

If you need to decode first, then, you can support longer lines by
turning off jets since you won't need to allocate buffer space for all those
zeros.

Why do you want to turn off jets?  The only reason I could think of would
be if you wanted to print at a resolution was not an integer multiple of
the jet spacing.  The 750 has a jet spacing of 6/720 or 1/120.  360,
720, and 1440 are multiples of the jet spacing with factors of 3, 6, and 12.
But what if you want to print at a resolution like 1140 DPI?  That's 9.5*120.
The first jet can print a line, but, the second jet cannot.  It's not
positioned properly.  But the third jet can! You can actually use 24
of the 48 jets to achieve 1140 DPI assuming you can advance the paper
that precisely.

I don't know.  It's weird.  What I imagine is that none of the existing
printers can really make use of this command because the stepper motors
controlling paper feeds can't handle it, but, Epson is preparing for a
long term strategy.  There are probably some fancy printers in R&D now
that can or may support this kind of thing and Epson is laying the groundwork
in software early.

This is, of course, all rampant and baseless speculation, but, it does
seem to be consistent with the fact that someone at Epson obviously thought
there was some need to keep this command secret.
   
> The separations computed from the ESC(D
> commands that we've seen don't match up to the print resolution.

Yes, I do have to admit that that one perplexes me.  When I get home
I'll play with this command a bit more.

Eric