This is caused by the different ways that DOS and Unix handle the end of a text line. Unix ends a line with a LF (Line Feed, 0x0A) character, while DOS uses both a LF and a CR (Carriage Return, 0x0D).
In Linux, your printer setup tool should offer this translation as an option.
Staircase is when you printer prints like this:
Everything starts out OK, but when you reach the end of a line, it moves down but not back
(With a laser printer, the same problem will cause only one or even no lines to print)
If a printer is expecting both characters, getting only a LF tells it to only do a Line Feed without a Carriage Return, so that's just what it does, and that's just what you get.
There are at least five ways to fix this:
if $REALMODEL "$@" | $HPNPF -x $PERIPH 2> $LOG > /dev/null to if $REALMODEL "$@" | $HPNPF -x $PERIPH -n 2> $LOG > /dev/nullYou can download https://aplawrence.com/pub/netcat.hp.model See man hpnpf
David DiPieto offered these thoughts:
Date: Tue, 29 Dec 1998 16:05:40 -0500 From: David DiPietro <email@example.com> To: firstname.lastname@example.org Subject: printer stairstepping ... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I thought I'd share a little opost experience with you. When I install our application software I automatically add a "holdopen" for each parallel and serial printer to append the <cr> to <lf> as you mention in your printer discussion. Most of our sites now involve some kind of networking and printer sharing. I had been putting the high-speed lasers on the parallel ports on the SCO Unix server but starting having a problem with Windows applications printing graphics. I would often loose data or get garbled graphics. I finally decided to take the time to figure out what was going on using the hex dump mode on a Lexmark Laser. Apparently, and with understanding, having opost onlcr turned on will do a straight binary filter of the printer data replacing all <nl> with <cr><nl> - even if it occurs in the middle of a raster graphics string. This could - and will most likely - reak havoc on the output! You may want to address this in your discussion. In my case, the problem was solved completely by turning on the auto <cr> at the printer. Dave DiPietro/Abacus Systems Inc. (973) 875-9900
Got something to add? Send me email.
More Articles by Tony Lawrence © 2013-07-18 Tony Lawrence