Moving to vte, where this would be done.

I wonder on the saneness of the feature...

It is actually a wonderful feature.  I have had to use PuTTY for a long time under Windows® to provide this functionality to me for various reasons.  Hardware terminals supported this functionality so that users could use printers at their desk if they had them, as opposed to sending to a "workgroup" printer or whatever, though I used PuTTY to send stuff from remote SVR4 and Linux servers to the local printer if I needed a printout of something—say, the results of an SQL query or something in hard copy.  Lynx and PINE also support this feature of the terminal.  I have a shell script that I wrote to be able to print files or standard input, as well.

The way that the feature works is relatively simple; the full printing interface is defined as the following (from http://astronomy.swin.edu.au/~pbourke/dataformats/vt100/):

Printing:

 *  ESC [ i           print page
 *  ESC [ 0 i         print page
 *  ESC [ 1 i         print line
 *  ESC [ ? 4 i       auto print off
 *  ESC [ ? 5 i       auto print on                
 +  ESC [ 4 i         print controller off
 +  ESC [ 5 i         print controller on

The only ones that are used in most applications are ESC[5i and ESC[4i, because they are the most useful.

I was just about to report this feature request myself when I stumbled upon it already in the bug tracker.

It shouldn't pose a risk to users, even when enabled, however, in the interest of not taking someone by surprise, this should be a setting in a terminal profile that can be enabled or disabled, and disabled by default.  I will attach the shell script that I wrote when I was working with a heterogeneous UNIX network that I have used quite a bit for an example—when run under bash or ksh, it should print the file specified on the commandline (or stdin if the file is "-").

The biggest advantage to this is if you have a printer configured on your local host machine that the target UNIX or UNIX-like machine cannot talk to, you can feed whatever through to your own machine and run it off.

One thing that PuTTY did was pass the output from the terminal printing session directly to the printer, without translation.  It would be nice if this feature could have a single option (aside from being toggled on/off) that permitted you to do the same thing with GNOME Terminal, where, if set, passed the raw output of the print session to the printer, or, if unset, passed it through as a regular file to the printer system (e.g., print a PostScript document to a non-PS printer, or use it to print an image or other document on the other machine).

It is also insanely useful for quick run-offs of man pages when you are working with a ton of UNIX-like boxes, regardless of location.  I have used this script on SDF (http://sdf.freeshell.org/) to run off man pages there, and print them here.

Created attachment 68984 [details]
Shell script (ASCII/Unicode control chars) for VT100 Printing

Do use an editor to view this file, or view it in the browser—it contains character codes U+0018 and U+000C (ESC and FF) for controlling the VT100 terminal to start/stop printing and emit a form-feed when finished.  I have not (yet) added a flag to suppress the FF character or ask for it, because the setup that I was using at the time always required it after the last page of printing when printing text, and I was generally piping text into this script to print.

I have run into the need for this functionality again, and I no longer work in a workplace with a Windows environment, so instead of PuTTY, I used xterm, which has this functionality.

Looking at this report a little more, it would seem that the description should be changed to something along the lines of "vte is missing VT100 Media Copy implementation".

While I am not a wonderful C programmer, this has become enough of an impediment to me that I need to implement this functionality one way or another, so closing this bug has become a mission for me.  I do not know how long it is going to take me to implement it, because when it comes to C programming and GLib too, I am inexperienced enough for the time being to be considered incompetent for the task, I think, and while the functionality that I need is really only a subset of the Media Copy functionality of the VT100, it is probably best to implement it all at once or not at all, in the interest of being able to support applications that make use of that functionality, however rare they might be.

Comments, particularly from Mariano?

Patches are welcome.

I am pretty sure I've found the areas of the source code to modify, and I may be able to come up with something soonish, hopefully.  I keep dipping to xterm here and there or working around it using ssh creatively, and it's getting kind of annoying.  :)

*** Bug 473147 has been marked as a duplicate of this bug. ***

Humm, the URL for the spec is dead now.  Do you happen to have an updated one around?

Well, that stinks.

At least there's the Wayback Machine.  However, the most recent version of the page there is pretty old, the site's admin banned the Internet Archive from crawling the site sometime after July 20, 2005.

http://web.archive.org/web/20050720085952/http://astronomy.swin.edu.au/~pbourke/dataformats/vt100/

http://is.gd/9ViY

Today is not work yet, when gnome-terminal see the start and the stop characters the file is sent to the screen and not to the default printer.
To do this I use other programs like putty that have this feature.
Personally I would like to use gnome-terminal graphically why it works very well and I would go completely on linux.
I do not understand why this simple and convenient features not yet been entered,
the program must send to the default printer all characters after having see the sequence: esc[5i until the sequence esc[4i

(sorry for my english)
Corrado

Going back to the initial comments after my filing the bug:

Yes, I agree that the UI concerns for such a feature are worth considering.  Ideally, the data between the two escape sequences ought to be considered data to be launched in some external application.  I imagine that popping up the data in a gedit session would be enough, since one can easily hit the print button from there or just close the thing entirely.

What of binary data?  That's a tougher problem, since the spec doesn't seem to have any room for any sort of mime type heading.  

I think that defaulting to opening in gedit would suit the needs of most users of this feature.  It may be possible to do away with both Surprise Print Job and Yet Another Configuration Option by taking this path.

One other thing worth mentioning is that the /etc/vtprintcap from the vtprint package in Debian or Ubuntu has a few more control characters for different terminal types that support the equivalent of ^[[5i and ^[[4i (but no other features of that vt100 print spec, it would seem).

So, this is only about plain text?  What if an app wants to print Postscript?  I was thinking that maybe we pop up a print dialog or something and user can cancel it.  But text vs postscript is my main question right now.

Many applications such as Cobol print data in plain text,
for example if I connect my ssh client with a distant connection to the server
for print the data I will first have to redirect to a file and then taken by ftp and then print it using the "lp textfile" or "gtklp textfile".
By transparent printing this job will be easier.
The commands of start and stop can be read to the terminfo file
for vt100 are:
mc4 = \E[4i, mc5 = \E[5i

sorry for my english

Corrado

I often use it for PostScript or PDF or even PNG graphics---the point of the functionality is that it is generic.

So, I'd have to say that I disagree with Nick re: opening the captured buffer in a text editor by default.  I think that really there should be one of two ways to do this:  (a) introduce a preferences option for it in the profile preferences, defaulting to off, or (b) only introducing the configuration key for it in the gconf database, and not exposing a UI for it at all.  The rationale that way being that it's a function that only advanced users would likely have.  Either way, if the print sequences are used, *and* the printing capability is disabled, GNOME terminal should ask if that is what the user intended.  They can then enable printing from the question dialog, and optionally tell GNOME terminal to piss off and never ask that question again.

I think it's a decent middle road.

Also, nick, the data type coming through the stream is pretty easy to detect, since we can just invoke /usr/bin/file on it.  Probably the best thing to do, though, is to take incoming data that's bracketed with the escapes and just pipe it to lp or lpr.

(Actually, there should be a way to set the print command, much like in PuTTY, since maybe the user would want to do something like "lp -o number-up=2 -o cpi=15 -o lpi=8" if printing plain text over the network, or "lp -o sides=one-sided" if printing things that should not be duplexed and the default is to duplex.  The point being, the user should utterly and absolutely be in control of what to do.  If they then want to use a helper script to open all their VT100 print jobs in gedit, hey, more power to them.

Created attachment 123928 [details] [review]
(Incomplete) patch for adding MC functionality to VTE

I have begun working on this, though I am a bit lost right now on the next place I need to find to finish up.  I have media copy recognized by a handler now for PRINT_START and PRINT_END sequences, but what I need to find next is the terminal input handler such that when between START and END media copy sequences, the output can be shunted through a pipe instead of into the terminal's buffer.  Hopefully that won't take too long to find.

After I get media copy _working_, I can add polish.  Right now I am going for just getting a pipe opened to an 'lp' process on the system, and dumping everything bracketed within a media copy session to that pipe.  The only other thing then left would be to add two more properties: one which is an enable/disable flag for the MC functionality, and one which is a pointer to a string of the command to pipe the MC output to.

(In reply to comment #15)
> I often use it for PostScript or PDF or even PNG graphics---the point
> of the functionality is that it is generic.
> So, I'd have to say that I disagree with Nick re: opening the captured
> buffer in a text editor by default.  

Okay, fair point.  The file(1) magic is a reasonable approach, and the
devil there is in the details.  I'm not sure how many other systems use
file(1) on streaming input.

> I think that really there should be one of two ways to do this:  (a)
> introduce a preferences option for it in the profile preferences,
> defaulting to off, or (b) only introducing the configuration key for
> it in the gconf database, and not exposing a UI for it at all.  

I am unfamiliar with GNOME HIG rules on the opening of arbitrary files.
I am, however, familiar with Firefox's mechanism for dealing with
external launchers, and with the Nautilus "open with" context menu
option.  Is there anything equivalent to the Firefox "what do you want
to do with this file?" dialog that ties into the Nautilus "open with"
logic?  What does Epiphany do?

One other thing to consider here is the potential for abuse.  Imagine a
user running irssi in a gnome-terminal, and some malicious user manages
to get a literal ^[[4i to appear in the channel.  From then on, the
terminal appears hung and no amount of ^Qing will bring it back.  Any
support for this feature ought to have a "Don't print!  Just keep
displaying in my terminal!" button one can hit mid-stream.

Consider also a remote connection that breaks mid-transmission.  How do
rxvt and xterm handle these situations?

My aim was to implement the standard functionality---e.g., what PuTTY, xterm, and old DOS terminal emulation software implement, with a sane set of defaults.  That is, printing support disabled (and remote printing requests not honored) by default, unless the user sets up that functionality for themselves, and this would be a GNOME Terminal profile-specific thing so that one could configure a dedicated profile for running applications that use the remote printer support.

Historically speaking (and this is what applications that use the functionality assume), the VT100 printer is a dedicated form-feed dot-matrix printer.  Of course, one does not have to actually _use_ it that way and it's very useful to be able to dump postscript to a terminal wrapped around control sequences for printing.

As far as misbehaved applications such as an IRC client, IM client, or MUA which lets escapes pass through unfiltered, this would be a bug in the software itself.  The user can work around such afflicted software by not executing it in an environment where remote printing support is enabled, or (of course) fixing the bug.  This is what xterm and PuTTY users already do today.  That having been said, though, I have the feeling that this functionality is going to be used by a very niche segment of the GNOME Terminal userbase; I am the only person I personally know that will use it, for example.  Most other people I know didn't even know terminals had that capability, except for in passing ("why does Lynx ask if I want to print to my attached printer?  How could it do such a thing?" and similar).

It is not unreasonable to, say, add a status bar to the GNOME Terminal that could be optionally enabled and display various information about what's currently going on.  Then, the remote printing support could have an interface that enables the user to stop spooling just by clicking on it, and it could show various things like the emulated terminal type, the current row/col, and other information that would be generally useful.  This would be more in the style of a DOS terminal emulation program.  However, such a change is (IMHO) outside of the scope of this bug report.

Here's a reasonable summary of what functionality will be added to vte:
  * Support for user-toggling of printing support through
    the vte application.
  * When media-copy start request is received:
    1.  Open a temporary file to hold the contents of
        the media-copy.
    2.  Send the data received to the temporary file
        _instead of_ the terminal display.
    3.  Continue until the media-copy stop request is
        received, the terminal is disconnected, or the
        terminal is being shut down.
  * Send the temporary file to the spooler, by default
    'lpr', or whatever command the user has set their
    spooling to.  This enables a user to write a shell
    script to handle their print jobs specially (also
    not printing them at all, but just capturing to a
    file, if desired).  By default, we'll let the
    spawned process clean up the temp file, lpr can be
    told to do that by passing the "-r" command line
    switch, for example.  A user shell script can do
    it automatically.

Why a temporary file?  Because sometimes print jobs can be several tens of megabytes.  It's not very efficient to print large documents that way, but it is sometimes desirable (especially if the document is postscript or PDF or something).  It'd _definitely_ not be desirable to keep the entire thing in memory and then open pipes to deal with it---I don't assume that I've infinite RAM to work with here, and I don't intend on streaming the document since that can significantly slow down the process of fetching it in the first place.  It also makes it insanely easy for the user to be able to write their own shell script to handle the print job, and I can come up with a few example scripts to throw in to showcase how things would be done that way.

Thanks for the patch hooking this up.  I have a different design planned in my mind.  Going through gtkprinting for sure.  I like the Nautilus "Open with" dialog idea too and have been thinking about it.  Would be a bit harder.  

In my design, there is no on or off, but signals.  Vte will simply call signals on receiving the request.  gnome-terminal then will implement printing by connecting to the signal and opening a GTK+ print preview or print setup dialog.  Something like that.

Anyway, will check this out again later.

Hi Behdad,

Well, I don't think there's any harm in having multiple implementations to look at and evaluate, from multiple points of view.

What if libvte provided a default print handler, and the terminal emulator implementation could override it if desired?  Say, using the following functions:

  vte_set_media_copy_enabled(gboolean value);
  vte_set_print_handler(function_pointer cbHandler);

Then if cbHandler were NULL, libvte would use its internal handler, and if cbHandler were non-NULL, it'd use the function pointed to by cbHandler to handle printing.  cbHandler's declaration would be:

  void cbHandler(const char *tmpFilename);

And would simply take the name of the temporary file as its only parameter.  Then it could invoke a print dialog, or whatever.  libvte's default print handler (which would be used if vte_set_print_handler() were never called, but vte_set_media_copy_enabled(true) were called) would then simply use a UNIX command to feed the print job to.  If the user checks the "use libvte printing" checkbox in the terminal emulator's UI, the user would get the chance to specify a UNIX command to run (using something like %f as the placeholder for the temporary file) for libvte to call to to do the work (or leave it blank for the default of 'lp %f' or 'lpr %f' to just spool it to their default printer).

In any case, I'm still not there yet, since I haven't quite figured out how to get the raw string between the start and finish handlers.  I was looking at the vte_terminal_process_incoming() function in vte.c, and thought I'd had it figured out, but while I get the characters, I get them after some form of post-processing involving carriage returns and newlines out.  However, before that point in the code I think that the blob is the whole chunk, which may include stuff that we're not interested in before a START or after an END request in the stream.  From the relatively little amount of time I had last night to work on it, it looked like after the string is tokenized and the sequences are parsed out of it, so are the other special characters---and what I want is to get them unmodified until an END request comes in, well, sort of.  I also need to ignore (drop) ANSI escapes (color changes, cursor positioning commands, etc.), since those could be embedded and they don't make the printout look very nice.

Oh, or maybe it'd be even better if vte_set_print_handler() above were really named vte_set_media_copy_handler() since I suppose the UI could try to be creative and do something like open it as a file.

Though, the more I think about _that_, the more I think that it ought to be left to another feature---say, libvte maybe optionally supporting the use of something like the lrzsz package and having support for firing a signal when a ZMODEM transfer comes through so that a Save File dialog can appear (possibly with an additional checkbox to open the file after the transfer completes).

As retro as it sounds, it'd definitely be cool, and systems like SDF still support that type of transfer.  And if that were done it'd be nice to be bidirectional---e.g., be able to send files using something like ZMODEM, too, though sending them probably wouldn't be automatic since the user would have to inform the remote host that it wants to send a file.  But hey, if you're already in a terminal on the remote host, ZMODEM over SSH is really quite a fantastic idea (and it'd work with things like remote instances of lynx, if you wanted to do that for some reason).  I can definitely see myself using something like that, though.

See bug 79276 for Zmodem support.

Created attachment 124984 [details]
How wrq reflection menage the transparent printer

This is a panel of printer setup of wrq reflection for windows, terminal emulator for unix/linux.

Please see the rxvt-unicode or urxvt how solve the
transparent printer function see the "print-pipe" configuration.

Part of the manual:
print-pipe: string
Specify a command pipe for vt100 printer [default lpr(1)]. Use Print to initiate a screen dump to the printer and Ctrl-Print or Shift-Print to include the scrollback as well.

Example:
URxvt.print-pipe: gtklp

This print to the delault printer the screen contents or the file delimited by esc[5i and esc[4i

regards

*** Bug 532153 has been marked as a duplicate of this bug. ***

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/911.