Subject: garbled printing

From: [email-masked] (Alexander E. Christensen)
Date: Thu, 8 Dec 1994 07:35:37 GMT

My pine system captures the text, and then I print to the local printer, 
but the messages are all garbled and don't make sense anymore.  It seems 
to read different characters each time, but never the whole message.  
Any suggestions?  Please mail me or post here.  Thanx.

-- 
| Chester Francois Bolero     | "There's no 'c' in 'orange juice,' but if | 
| [email-masked] |  there were, it would stand for 'color.'  |
| You can call me Al.         |                    --Some guy named Derek |

---

From: [email-masked] (Gunther Anderson)
Date: Fri, 9 Dec 1994 16:53:14 GMT

Alexander E. Christensen ([email-masked]) wrote:
: My pine system captures the text, and then I print to the local printer, 
: but the messages are all garbled and don't make sense anymore.  It seems 
: to read different characters each time, but never the whole message.  
: Any suggestions?  Please mail me or post here.  Thanx.

Could be your terminal program.  Using QuickLink II for DOS from home, 
Pine succeeds in printing the first and last 20 lines of any given 
message (more or less).  Using Procomm (any of several versions for DOS 
and Windows), printing works perfectly.  You might also, if you are 
dialed in instead of telnetting, check your flow control.  Printing 
causes a seriously dense stream of data to come over the line.  If your 
machine overflows its buffers and can't stop the data flow, you'll get 
garbage too.

But I doubt it's Pine's fault.

gunther Anderson

---

From: Terry Gray <[email-masked]>
Date: Sat, 10 Dec 1994 10:00:44 -0800 (PST)

Alexander et al:
Let me reinforce what Gunther said:  I think 99% of "pine printing 
problems" are either due to communications software that doesn't 
understand ANSI escape sequences for printing, *or* (in the dialin 
case) flow control problems.

We didn't understand how big a problem software flow control was 
until 3.90 came out... we changed pine to intercept flow control 
characters so that users would not see Pine "wedge" mysteriously if a 
mis-type or noise generated a control-S, but that did bad things when 
printers, modems, or comm software was depending on s/w flow control.

So in 3.91 we added the "preserve-start-stop-characters" feature, so that
Pine could be configured to respect s/w flow control characters (if the
operating system did) for those folks who needed them.  Enabling this feature
should make Pine 3.91 behave the same way as earlier versions. 

Then we discovered that some operating systems don't enable software flow
control by default.  So in 3.92, the "preserve-start-stop-characters" 
feature will do more than simply "not ignoring" them, it will try to force
the OS to pay attention to them.

So here's the sequence of things to try if you have pine printing 
problems:

 1. CHECK FOR SOFTWARE FLOW-CONTROL PROBLEMS:
    A. Try enabling "preserve-start-stop-characters"  <- requires 3.91
    B. If that doesn't help, verify that the OS is enabling s/w flow
       control; if it isn't, you can either change that in a global 
       .login script, or as a worst case, wrap pine in a script that does 
       it.  By the way, on our AIX systems, we had to execute "stty -ixon"
       followed by "stty ixon" --no one here knows why the first stty
       is needed.  (Note that explicitly enabling s/w flow control in the OS 
       will not be needed in 3.92).
 2. CHECK YOUR COMM SOFTWARE FOR ANSI PRINTING CAPABILITY
    A. After ruling out s/w flow control problems, if printing still 
       doesn't work, the odds are that the PC or Mac comm s/w is at fault.
       I don't know how to determine this other than via trial-and-error
       and word-of-mouth.  
    B. The "ansiprt" utility included in the pine distribution can also 
       be used for testing.  It simply sends the specified text file to 
       user's terminal device, bracketed with the ANSI escape sequences 
       for print diversion.  This is just what Pine does as well (although
       some versions of ansiprt offer a few options not available via Pine.)
 3. POSSIBLE OTHER PRINTING PROBLEMS
    A. Printing via Pine's "attached-to-ansi" facility to a postscript-only
       printer.  Pine does not yet have the ability to encapsulate text
       into postscript, ala "enscript", so the custom print option using 
       enscript and ansiprt will be needed in that case.
    B. Other printer-specific configuration problems.  For example, 
       whether or not the printer needs a trailing formfeed to eject the 
       last page, or a control-D, or non-Unix newline conventions, etc.
       Many of these problem will also require using the custom print 
       command option and "ansiprt".

If others have additional specific printing problems and solutions, it 
would be good to contribute them for incorporation into a "pine printing 
faq"...  (Nancy, what d'ya think?)

-teg