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" <[EMAIL PROTECTED]> > Subject: Printing support (Docs and requests for code changes). > To: screen-users@gnu.org > > 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 >
_______________________________________________ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
