Printing support (Docs and requests for code changes).

[Dan Mahoney, System Admin]

I've just done quite a lot of research into how to get screen to 
gracefully handle printing, and I would like to suggest that there should 
be some changes made to screen, and/or the docs.

Screen specifically depends on whether or not the connecting terminal has 
a printer defined by looking at the po/pf capabilities in the 
termcap/terminfo database.  The problem is that (under FreeBSD at least) 
the vt100 specification does not have a po/pf entry.

I was able to add these to screen using the following:

termcap vt100 po=\E[5i
termcap vt100 pf=\E[4i

However (ironically) in the hard-coded vt100 emulation that screen 
presents to an application, there is no defined po/pf capability presented 
by default.

Still, programs like pine, and lynx, send the printing escape codes 
(ignoring the terminal capabilities being present or not).  Printing 
generally takes only a few seconds on any modern connection.

The problem comes in when dealing with any attached printer.  Screen does 
NOT have the option to simply "pass" these codes through to the terminal, 
but instead feels the need to "buffer" the print, constantly sending tiny 
chunks of "printer on" DATA "printer off".

Results of this are:

1) Some SSH apps (like SecureCRT and putty) print one page per chunk of 
data.  Thus when printing a 40-line email I get 20-40 pages of garbage.

2) SecureCRT on my end has an option to "buffer" the printing so it only 
prints when there is a pageful of data, forcing the user to select a menu 
option to "eject" the last page.

3) SecureCRT interprets the "printer off" signals, instead, as LINE FEEDS, 
so the message gets broken in odd places.

I could understand how this buffering "feature" might make sense on a slow 
link, where one was trying to print a 200-page document and still wanted 
the screen functionality while your printing-app chunked the data down the 
line.

But let's look at reality here.  Most of us just want to be able to print 
an email or two reliably.

Can someone PLEASE add an extension to the "printcmd" that disables the 
buffering?  This should in theory be EASIER to code than what's in place 
now.  Just don't intercept the escape sequences, send them through as-is, 
and we, as screen users, will agree not to navigate out of the app window 
doing the printing, because maybe THEN we have the CHOICE to have screen 
buffer the output and mess it up.

Thanks,

Dan Mahoney

--

<Gushi> And hello kitty does not have a mouth.
<bizzy> . o O ( oh yes she does )

EfNet #macintosh, 2/21/01, some ridiculous hour of the morning

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------