On 8/2/05, Robert L Krawitz <rlk@...> wrote:
> Date: Tue, 2 Aug 2005 18:56:09 -0600
> From: Mark McVea <mark.mcvea@...>
> On 8/2/05, Robert L Krawitz <rlk@...> wrote:
> > From: Mark McVea <mark.mcvea@...>
> > Date: Tue, 2 Aug 2005 15:31:04 -0600
> The way the run length compression works is that the data is formatted
> > as
> > (counter data...) (counter data...) ...
> > Counter is a single count byte. If the counter value is 127 or less
> > (0-127), then the following (counter+1) bytes are uncompressed data.
> > For example, if the counter value is 10, the printer expects 11 bytes
> > of data.
> > If the counter is 128 or more (128 to 255), then the next byte is a
> > single byte of data that's repeated (257 - counter) times. For
> > example, if the counter value is 200, the next byte is repeated 57
> > times.
> That makes more sense. However, in the example I used, each ESC i
> command was followed by, for instance, several dozen FD 00
> bytes. If this is just 4 non-printed dots, why not move directly to
> where the printing occurs and start there?
> Because a pass has to start at a certain horizontal position. Maybe
> there was a nozzle that shouldn't be printing anything.
> Also, FD 00 means (257 - 253) * 4 dots (2 bits per pixel), or 16
> dots. I don't know why you'd do FD 00 FD 00 rather than F9 00.
Well, I generated the code by using the epson drivers on Windows, with the=
print driver set to print to a file. The file I was printing was a thin,=20
horizontal black line located near the top center of a cd template using=20
cd-label printing software, since ultimately I need to print to the cd. As=
for why it used, say, 25 consecutive FD 00's instead of something simpler=
like 9D 00 which would do the same thing, I don't know. I'll just assume=20
it's the software not being too intelligent. Needless to say, when I=20
instruct the printer, I'll used 9D 00. :)
The other rule is that the data must end at a row boundary -- you
> > can't compress data over multiple rows. Finally, keep in mind it can
> only print at a resolution of 360x120 DPI in a single pass, since the
> > nozzles are spaced 1/120" vertically and can only print every 1/360"
> > -- if you want a higher resolution, you have to interleave ("weave")
> > the data. *THAT* is not a lot of fun.
> I assume that's what is happening with my horizontal line printout since=
> prints 6 repeats of ESC ( $ (set horiz. position) with ESC i before using
> ESC ( v to change its vertical position.
> Yes, although 6 repeats seems a bit odd.
It does seem odd. Would 6 repeats indicate that it's trying to print at a=
resolution much higher than 360x120?=20
> If anyone can clear up what is happening I would very much
> > appreciate it. I plan on writing a paper on my research within the
> > month and would love to acknowledge any help that I've received.
> > That's fine, but you might be able to save yourself a lot of effort by
> > using the Gutenprint library as the core of your application (assuming
> > that it can be GPL-compatible, of course).
> My hope for this project was to have the printing pattern well
> defined in advance and thus just have a program transmit the
> required ESC/P data over USB to the printer. What extra abilities
> would Gutenprint provide me if I already have the application
> written to send ESC/P to the printer, and if I don't want any
> dithering or weaving?
> If the data's completely pre-generated, that's fine. However, unless
> you want to print at a resolution of 360x120 DPI, you can't entirely
> avoid the weaving.
Well, once I have the kinks worked out with regards to instructing the=20
printer to print, my next task will be to determine how the substances I'm=
trying to print respond to different resolutions. When it comes to proteins=
on a glass slide, 360 deposits per inch is a fair bit and will hopefully be=
enough to achieve the results I'm looking for. If not, I will have to resor=
to multiple passes over the same location. Since I am aiming for a very=20
simple dot pattern rather than complicated dithering, the multiple passes=
shouldn't be too hard.=20
> Robert Krawitz <rlk@...>
> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lpf@...
> Project lead for Gimp Print -- http://gimp-print.sourceforge.net
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton