Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!HGRRUG52.BITNET!HOESEL
From: HOESEL@HGRRUG52.BITNET
Newsgroups: comp.sys.atari.st
Subject: Re: DeskJet speed / screendump
Message-ID: <8906112040.AA14807@ucbvax.Berkeley.EDU>
Date: 11 Jun 89 21:43:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 45

I just finished a first version of a small screendump program that does
use the mode 2 compaction for the deskjet (plus) printer
That does work fast (in about 6 seconds for a screendump). I presume that
the laserjet drivers do not support this compaction, because it is not a
standard PCL III feature.
So anybody who wants to write graphics software for the deskjet USE MODE 2 !!!

While I was busy with testing the screendump program I discovered what I think
is a bug in the printer (which you only see if you do thinks that the printer
does not like). To explain what is wrong I have to give you some information
about what is going on internally in the deskjet. It has a 16Kb input buffer
and the rest of the internal memory is used for the pageformatter. All input
to the printer first goes through a parser and evenually ends at the page-
formatter. A laserprinter also has a pageformatter and this is used to
create the page in memory of the printer, before it is being printed.
The deskjet has a memory limited pageformatter. This allows one to do
overstrikes, software generated underlines, scroll back without actually
moving the printhead twice over the same spot on paper. If memory fills up
then the first line of 50 dots vertically is printed.
The same is true for graphics: the heads starts moving if memory fills and
the first 50 dot lines are printed (there is a special command that
sets the pagewidth for graphics use. This increases the amount of data
that can be send before the head moves).
Now comes the bug(?) if you send non-graphics data in between two dot-lines
then these force the printer to send out the data and the non-graphics data
(this happened by accident, because I did tell it the wrong number of
graphics data). If this non-graphics data is normal-printable ascii then
this is printed. At the next dot-line this is printed again (one dot position
lower, but over many dots vertically). This results in too much ink on the
paper, and that is something the pageformatter should overcome.

I think that this is happening with the laserjet-driver from signum: it seems
to print only one row of dots at a time, which takes forever if you would print
a full page at 300 dpi. maybe there is some non-graphics code between the
rows to position the printhead.

It is not only graphics data that causes the printer to print too much ink
on the same spot. I used a deskjet driver for 1st-word plus and it
simulates bold printing by printing twice (instead of using the buildin feature
for bold-printing). Also using a laserjetdriver on a IBM with wordperfect
did simulate the boldprinting with the result that some spots got twice the
ink they needed. I think that the pageformatter should prevent this!!!

frans van hoesel
HOESEL@HGRRUG52