Subject: Re: Problem with CR/LF Printing Text to HP LaserJet--Progres
To: None , None <netbsd-users@netbsd.org>
From: Richard Rauch <rkr@olib.org>
List: netbsd-users
Date: 10/22/2003 17:25:37
Re. http://mail-index.netbsd.org/netbsd-users/2003/10/22/0008.html

[Long rambling reply.  Feel free to skim/skip/skimp.  (^&]

[Barry says that my Bourne shell script doesn't work for him.]

Very odd.  I wrote that script (and have it installed in my own
/usr/local/libexec/printer-filters/ dir) precisely to solve this problem
for my Laserjet.  Are you sure that you are getting the filter properly
invoked?

As someone else said, the filter is simply putting a CR before every LF.

I can't remember if I originally tried to send an escape code to the printer
to tell the printer to accept single LFs for EOL.  I think that I did, but
it becomes much more printer-dependant then.  If the processing to do this
were significant compared to the computer's capabilities, I'd write it in
C with a printer-specific prefix to kick the printer into the appropriate
mode, and then just copy {stdin} to {stdout}.  (^&

(Printer-dependance can be an issue.  I've used two Epson dot matrix printers
and one HP LaserJet with my systems.  Using an LF->CR/LF filter works with
them nicely without change; using escape codes is probably at least different
between the HP and Epson printers, and maybe between the two Epson printers.)


It seems to work for me, though I usually stuff ASCII files into "a2ps"
and have the whole thing shoved through GhostScript.  (^&  (The latter
gives me n-up printing and lets me easily do duplex printing etc.)

("Eeasily".  Err.  I use psutils to separate pages, which someetimes gets
confused if the PostScript document lacks proper structure.)


I keep the "lp" entry for a true "line-printer" effect though I seldom
use it.  "lp" uses that printer filter.

I do not use MagicFilter.  (^&


I suggest that you take out the filter and get back to where you get the
stair-stepping.  Then put in a filter.  Double-check the line-continuation
markers (\ at the *very* end of every line but the last; no spaces allowed
after the end-of-line).  (For some reason, it seems to be popular to put a
: after the last entry and before the first entry of the next line, though
I don't know if anything really requires that or if that's just a defense
mechanism that some people have.)

If you used my filter and have filtering enabled properly, it should *not*
stair-step; that is exactly what the filter fixes.  Make sure that you've
enabled filtering, or else use a "dummy" entry to convert, as mentioned
elsewhere.  I use dummy entries presently:


On my main machine (much faster than the one with the printer physically
attached), I have the following printcap entry (one of *many*; I use printcap
entries to define processing to apply to a file rather than relying on some
complex filter to guess what I want):

 /~~~ printcap

ps|PostScript printer:\
        :lp=/dev/null:sd=/var/spool/lpd/ps:lf=/var/log/lpd/ps:\
        :sh:mx#0:\
        :of=/usr/local/libexec/printer-filters/ps:\

 \___ printcap

(Hm.  I don't need that trailing \.  I wonder why I put it there?  Maybe I
had another line after that that I deleted?  Anyway, as long as the next
line is blank, that should be okay.  (^&)

Then *its* filter goes to the "raw" (no CR/LF conversion) printcap entry on
the machine with the physically attached printer.  Here's the "ps" filter to
do that:

 /~~~ ps filter

#!/bin/sh

/usr/pkg/bin/gs -sDEVICE=pxlmono -q -sOutputFile=- -dSAFER -dNOPAUSE -dBATCH - | lpr -Puraw

 \___ ps filter

(That is all on one line in the file.)


If you change "ps|PostScript printer" to your default "lp" printer, and
change the Bourne script filter to the one using AWK that I gave before,
I think that you will get what you want.



NOTE that the "ps" printer has an "lp=/dev/null" capability.  That is where
the (standard-output) output of the printer filter goes.  I just throw it
away.  The *printing* output is already sent (by the filter itself) to
the "uraw" printer.

"uraw"s entry is then a basic, unfiltered network printer.


You won't have to do this song and dance if the "lpd -r" option works.
I can't remember if I was aware of that at the time that I wrote the
above.

I can't think of any good reason NOT to use "-r" with lpd, if it works.
I initially spent a LOT of time pulling my hair out over why my filters
"weren't working".  Until I realized that if/of filters were not respected
for network printers.  (The point is either not documented, or is not well-
enough-for-me documented.  (^&)


The chain is something like this:

 lpr -=>
   [ps] -=>
     ...printer-filters/ps -=>
       ghostScript -=>
         lpr
           [uraw] -=>
             [network] -=>
               [other computer] -=>
                 [raw] -=>
                   [printer]

It's a long chain, I grant, but it lets me piece together what I want to
do, rather than just passing it off to a program that someone else pieced
together and hoping that it comes out right.  (^&

And, basically, it lets me just say "print this to 'the postscript printer'"
and it Just Works.

I have a slightly different entry for 300dpi printing (ps300).  And for
even pages (pse300).  And for odd pages at 600dpi (pso600), plus all of the
bits that you can fill in from that (ps300, pso300, ps600, ...).  These
are filled in by alternate printcap entries and slightly different
printer fitlers.

You can add anything to that list that you're willing to write a printcap
entry and filter for.  (E.g., DVI files.)

You can even add a "magic" printer that uses a2ps or MagicFilter, or some
other voodoo.  (^&

I look on lpr/lpd as a web, or network, of filters and pipes.  You can
put a sink anywhere you want.  For *my* tastes, it is a shame to have one
central sink that everything pipes into, leaving all processing up to
the whim of that one program.

It also lets me avoid adding packages for formats that I don't care about,
and overhead for rebuilding lots of such whenever I have a flagday in
pkgsrc.


-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/