[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Printing support (Docs and requests for code changes).

From: Dan Mahoney, System Admin
Subject: Printing support (Docs and requests for code changes).
Date: Tue, 25 Sep 2007 14:11:44 -0400 (EDT)

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]