Re: Printing support (Docs and requests for code changes).

[Albert van Zyl]

I totally agree with Dan. May his wish come true.

> Date: Tue, 25 Sep 2007 14:11:44 -0400 (EDT)
> From: "Dan Mahoney, System Admin" <address@hidden>
> Subject: Printing support (Docs and requests for code changes).
> To: address@hidden
>
> 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
>