[X2Go-Dev] fuse and X2Go printing

[Oleksandr Shneyder]

Hi Stefan,

I would prefer the solution suggested by Morty. Actually, I already
thought about it and i want include it in new implementation of
x2goclient. X2goclient will simply check a spool directory on server and
download a print jobs in PDF format via existing libssh connection. This
solution is much simpler, no need a cups, lpr, or ssh daemon running on
a client and implementation is just the same for all operating systems.
I can also implement this solution in current version of x2goclient if
somebody will sponsor the development.

regards
Alex

Am 20.02.2013 09:51, schrieb 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
> _______________________________________________
> X2Go-Dev mailing list
> X2Go-Dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/x2go-dev


-- 
Oleksandr Shneyder
Dipl. Informatik
X2go Core Developer Team

email:  oleksandr.shneyder at obviously-nice.de
web: www.obviously-nice.de

--> X2go - everywhere at home

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20130220/457c336c/attachment.pgp>