And this is exactly it, and extreme thanks to all who helped out, and
especially to Jerry Banker who had the correct answer pretty much right
off the bat although the control character issues confused me into
thinking it was something else.
What was happening was a conflation of events: I could easily get the
stairstepping issue to go away when using a proper printer driver, but
the printer did not then interpret the printer control codes properly.
When using RAW devices/no drivers, the printer control graphics & bolded
text, etc, printed properly but no text because it was stairstepping
right off the page. However, we were additionally led astray because
converting the captured PCL output to PDF produced the same thing, i.e.
the graphics but no text. Another hitch in my gitalong was that I had
assumed that setting the CR Mode to : Convert LF to CR/LF would take
care of the issue, but Joel Yates @ IBM tells me that so long as you're
using /dev/null & not an actual device, this setting has no effect.
Adding this:
perl -ne 'chop; print $_,"\r\n"' | lp -dPRINTER
to our printer driver works a treat; Joel pointed me at lponlcr & xtod,
neither of which exist under the standard linux distros that I can find
(still looking for equivalents), which reinforces Wol's point. If anyone
knows of equivalencies, give a shout.
Again, many, many thanks to everybody here, I'm a happy sysadmin again.
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Dear Peter,
As the lp concept of printing is to temporarily capture a file (frequently
to the hard drive) as it is generated by an application, and then send it to
a defined destination once the file is completely created, it is possible
for system issues (such as number of open files) to impede the proper
creation of the file to be printed.
Don't forget also, that modern Unix (and linux especially) seems to assume that
all printers are postscript. That really cheeses me off, in that it's a right
pain if you actually want to control the printer yourself for some reason (like
in this case, sending HP control sequences to an HP printer!)
It's pretty much a certainty that, by default, this print job is being spooled
throught ghostscript. Which will detect it is a text file, and wrap it in the
necessary postscript code, fooling the printer into treating it as postscript
(if it's a postscript printer) or ghostscript will mangle it itself (if it's
not a postscript printer).
To my mind, modern linux printing is one of the worst bits of linux. It tries to force you to use
CUPS (totally ignoring the linux mantra of "choice"); while CUPS, even by the standard of
Unix, is exceptionally user-vicious. Just read ESR's "Aunt Tilley" diatribe about CUPS
... My worst experience is where I tried to connect to a network printer. I wanted to tell it where
the printer was, so I told it to NOT do a network scan. Next thing I knew, the configuration
utility had started (uninteruptably) scanning the network looking for printers ...
Cheers,
Wol
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
--
Peter Ivanick
Sr. Programmer/Analyst
School of Veterinary Medicine, University of Pennsylvania
Email: [EMAIL PROTECTED]
Phone: 215.573.2306 Fax: 215.573.8777
http://www.vet.upenn.edu/
-------
u2-users mailing list
[email protected]
To unsubscribe please visit http://listserver.u2ug.org/
