edgar@csri.toronto.edu (Edgar LeBel) (09/06/89)
Is it just me or does everyone with an Epson LQ variety printer have this problem: the 1.3 printer driver changes <linefeed> into <linefeed, carriage-return> when printing text, and inserts <CR, CR> after each line of graphic data, resulting in double-spaced text and images chopped into horizontal bands by extra linefeeds? Sending text straight to PAR: with a single linefeed separating lines works fine, as does WordPerfect, which uses its own driver. Changing the auto-linefeed DIP switch on the printer also has no effect on this problem either. On my previous, "Epson-compatible" printer I had the same problem under 1.2 and 1.1 so I wrote my own driver. Unfortunately, I don't have the necessary source code for a 1.3 driver, so I can't do the same. Could someone please: 1) mail me a 1.3 printer driver for an Epson LQ-510 (or 500/850/800/...) ? 2) mail me the source I need to write a 1.3 driver ? 3) let me know where I can get either 1) or 2) ? 4) convince me that this isn't happening ? Thanks for any and all replies. I will post any positive solutions. Hobie Orris (impersonating Edgar Lebel) P.S. Should one whine about these problems here or in comp.sys.amiga?
andy@cbmvax.UUCP (Andy Finkel) (09/07/89)
In article <1989Sep5.232119.19260@jarvis.csri.toronto.edu> edgar@csri.toronto.edu (Edgar LeBel) writes: >Is it just me or does everyone with an Epson LQ variety printer have this >problem: the 1.3 printer driver changes <linefeed> into <linefeed, >carriage-return> when printing text, and inserts <CR, CR> after each line of >graphic data, resulting in double-spaced text and images chopped into There are 2 possible problems you are having: a) your parallel cable is wired so that the Epson LF->CR/LF conversion is turned on b) your dip switches are set so that the Epson LF->CR/LF conversion is turned on c) both of the above The printer.device assumes (and needs to assume) that when it sends a CR the printer does a CR, and when it does a LF the printer does (only) a LF. Epson printers have the capability to act this way, settable by both cable and dip switch. See your Epson manual for more detail. >horizontal bands by extra linefeeds? Sending text straight to PAR: with a >single linefeed separating lines works fine, as does WordPerfect, which uses >its own driver. Changing the auto-linefeed DIP switch on the printer also has >no effect on this problem either. Then its probably your cable wiring, which is overridding the dip switch. (on my old Epson it was PIN 14, called AUTO LINE FEED) > >On my previous, "Epson-compatible" printer I had the same problem under 1.2 >and 1.1 so I wrote my own driver. Unfortunately, I don't have the necessary >source code for a 1.3 driver, so I can't do the same. This is available from CATS, as part of the 1.3 Native Developers Update Disk Set. However, to solve your problem and let you use standard drivers you probably won't need it. andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. Life gets pretty complex the minute you stop mooing. Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
edgar@csri.toronto.edu (Edgar LeBel) (09/07/89)
I wrote: >>Is it just me or does everyone with an Epson LQ variety printer have this >>problem: the 1.3 printer driver changes <linefeed> into <linefeed, >>carriage-return> when printing text, and inserts <CR, CR> after each line of >>graphic data, resulting in double-spaced text and images chopped into In article <7849@cbmvax.UUCP> andy@cbmvax.UUCP (Andy Finkel) writes: > >There are 2 possible problems you are having: > >a) your parallel cable is wired so that the Epson LF->CR/LF conversion > is turned on >b) your dip switches are set so that the Epson LF->CR/LF conversion is > turned on >c) both of the above > >The printer.device assumes (and needs to assume) that when it sends a CR >the printer does a CR, and when it does a LF the printer does (only) a LF. >Epson printers have the capability to act this way, settable by both >cable and dip switch. See your Epson manual for more detail. > >andy finkel {uunet|rutgers|amiga}!cbmvax!andy >Commodore-Amiga, Inc. > 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? Hobie Orris (impersonating Edgar Lebel)
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/07/89)
In <1989Sep7.090753.2043@jarvis.csri.toronto.edu>, edgar@csri.toronto.edu (Edgar LeBel) writes: > ... 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? Pulling pin 14 will do it, provided the correesponding DIP switch is set properly. AT any rate, it can do no harm whatsoever, even if the problem were something else, such as a bogus driver. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
jwright@atanasoff.cs.iastate.edu (Jim Wright) (09/08/89)
In article <1989Sep7.090753.2043@jarvis.csri.toronto.edu> edgar@csri.toronto.edu (Edgar LeBel) writes: | Before I pull pin 14 out of my parallel cable, I would | just like to confirm that this will solve the problem. I would suggest using electrical tape to cover the contact in the Centronics connector. I think it's better than surgery on the cable, especially if you don't make your own. (And hence can easily repair mistakes, shorts, etc.) -- Jim Wright jwright@atanasoff.cs.iastate.edu
daveb@cbmvax.UUCP (Dave Berezowski) (09/12/89)
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