🚀 go-pugleaf

In article <1989Sep7.090753.2043@jarvis.csri.toronto.edu> edgar@csri.toronto.edu (Edgar LeBel) writes:
>Thanks to everyone for answering my question.  A few responses
>(including Andy's) indicated that pin 14 on my parallel cable 
>(an official Commodore one) is to blame. It is called AUTO FEED XT 
>and causes the paper to feed one line "after printing", so the 
>manual says. Before I pull pin 14 out of my parallel cable, I would 
>just like to confirm that this will solve the problem.  The 
>documentation of pin 14 in my manual is cryptic (1 line of text). 
>Will disabling this pin make the printer interpret LF,CR as a single LF?
>
>As a test, I patched the printer command table in the EpsonQ 
>driver so that ESCE (return/lf) only puts out the lf.  I can 
>now  "cat >prt:" without extra linefeeds between the lines, but 
>that still leaves the graphics.
>
>Here is a sample of some graphic data captured with CMD:
>
>FFFFFFFFFFFFFFFF  0D0D  1B4A18  1B7200 1B2A26D002  FFFFFF 
>
>^-end of line 1^  ^^^^  ^^^^^^  ^^^^^^ ^^^^^^^^^^  ^line2 data
>  (I counted       |      |       |        |
>  2160 bytes)      |    18/180    |    set gr.mode (720 cols.)
>                   |    line     not in
>                   |    feed     my manual
>                   |
>                  WHAT'S
>                  THIS FOR?
>
>Will disabling pin 14 cause these two CRs to be ignored?  Does the 
>ESC J perform the actual paper advance, or does the CR?
>
0D0D	- carriage return (two of them, explained below)
1B4A18	- 24/180 of an inch line feed (not 18/180, can't mix hex and dec!)
1B7200	- select color Black (ignored by b&w printers)

	The carriage return is required as part of Epson's spec for sending
graphic data (it actually causes the printer to physically print the data).
The ESC J command performs the actual paper advance.  The fact that there
are two carriage returns instead of one is a minor quirk in the driver,
actually its there to insure that the print head returns to the home
position.  The first CR doesn't do this, it just causes the data to be
printed.  Returning the print head to the home position is/was an attempt
to get vertical lines to line up better by insuring that the print head
would always start from the same place.   BTW that's why uni-directional
mode is selected by all drivers; vertical lines appear wavy when printed
in bi-directional mode.  For some future release I've considered a preferences
uni/bi directional selection.  It would be useful if you were printing a
picture that didn't have any thin vertical lines or were using a printer
that had amazing horizontal dot alignment (I havn't seen one yet).

	daveb