[X2Go-Dev] fuse and X2Go printing

[Stefan Baur]

Am 20.02.2013 09:22, schrieb Moritz Struebe:
> On 2013-02-19 20:20, Stefan Baur wrote:
>> I can see that sshfs makes sense when you want to exchange files
>> between host and client, but for printing it sounds like overkill.
>
> Well, actually the best thing to do is probably letting the client "ls"
> every sec (it's prabably not worth the trouble to inotify) and then scp
> to temp. But it needs someone to code that. After all, a x2go started as
> a proof of concept rather then a product.

Uh, no.  You see, currently, I'm not using X2Go to connect via the 
internet, it's all happening in my local network(s), so I don't have to 
worry about encryption and compression for print data.  In this 
scenario, I'm simply letting the CUPS servers talk to each other 
directly, which works fine when the client is using Linux (or Mac OS, I 
guess - after all, the Apple guys kinda bought CUPS).

For Windows, I'm using the LPR Daemon that is an optional windows 
component, so to the server-side CUPS the Windows computer looks like a 
network printer.  For printers that aren't supported by CUPS (the 
el-cheapo GDI-only ones) I'm using a combination of redmon (a printer 
port redirection tool usually used with ghostscript for Windows to 
create PDFs) and a free PDF viewer: CUPS sends the print job in PDF 
format via port 515/lpr, redmon accepts it, passes it to the PDF viewer, 
which in turn uses the windows printer driver to create the print 
output. If properly set up, all this happens in the background, with no 
user interaction required and no windows popping up.
A bit of a hack for Windows, I admit, but it works just fine.

Now, it would be nice if that would work over the internet, too, by 
simply forwarding the proper ports through the already existing ssh 
tunnel created by X2Go.  That way the print data would be encrypted and 
compressed as well.

That's why I don't see an advantage in mounting a remote filesystem via 
SSH (which is a Pandora's Box of its own) simply to be able to print.

And even if you don't want to use LPR and redmon on Windows, there'd 
still be the option of setting up a netcat listener on the client that 
only accepts connections from localhost (the tunneled port connecting to 
it), have that one write its data to a file, and print upon completion.

Something as simple as (pseudocode, not actual bash/batch)

printfile=$(makesafetempfilename)
# note that we're using port 9100 - "raw" network printer mode
# rather than 515 with its LPR protocol overhead, so we don't
# need to have the windows LPD and redmon installed
while nc -l -s 127.0.0.1 -p 9100 -w 1 >printfile; do
    process_and_print printfile # this is where you call the PDF tool
    delete printfile
    printfile=$(makesafetempfilename)
done

would probably do the trick. Note that Windows netcat (at least the copy 
I found) doesn't support "-q", so you have to improvise with "-w".

The way netcat is called it terminates upon completely receiving the 
file, and the following tasks are not started before netcat terminates, 
so there is no need to check for completeness of the file.

Also, should a user fire off another print job before the while loop 
returns to its head and restarts netcat, CUPS will simply assume the 
printer is busy/offline and retry after a few seconds, so no print job 
is lost.

I'm sure that even integrating such code (with a listener and the option 
to pass a temporary file to a PDF tool) *directly* into the X2Go client, 
rather than having it as an add-on component, would be a simple task for 
a skilled programmer.

-Stefan