🚀 go-pugleaf

>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.

>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!!!

What? A bug in my printer :-).  First of all, the DeskJet and DeskJet+
have no page formatter.  It does not even have any sort of bit image buffers
except for graphics.  Instead we have a "task processor" and a "format
buffer" which builds commands for a custom chip which then prints the
commands.  In other words, the printer firmware never "sees" a bit image
of the text data being printed.  Text is not simply ORed into a bit image
buffer but rather passed to a custom chip for printing.  It would be
ALLOT of overhead to have the task processor scan each task and compare
with all other tasks for any characters that would overlap.  I'm sure
this does not make complete sense but the main thing to remember is
there is no page formatter or any other bit image sort of representation
of the text.

Any DeskJet driver that is bolding by double printing characters is
written incorrectly, plain and simple.  Since the DeskJet can algorithmically
bold all characters there is no reason to bold by double striking.

Dave Neff
hpvcfs1!neff