HOESEL@HGRRUG52.BITNET (06/12/89)
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
neff@hpvcfs1.HP.COM (Dave Neff) (06/14/89)
>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