HI Stefan, On Sa 10 Jan 2015 10:18:03 CET, Stefan Baur wrote:
Am 10.01.2015 um 09:39 schrieb Mike Gabriel:@Mike#1: Do you think we should open a wishlist bug to integrate my workaround with x2goclient and its ssh tunneling? IMO, my workaround is actually the "cleaner" way of printing through X2Go, but it might require some changes to cups-x2go and some server-side logic for a flawless integration.@Stefan: I have re-read your suggestion about tunneling LPR/LPD-like traffic. I don't think we should follow that road in X2Go because: o adding another SSH tunnel to the X2Go session DB is a PITA I have just gone through for telekinesis.I'm not sure why it would have to go into the session DB? *headscratch* What I was thinking of was a way to specify port forwardings in the X2GoClient sessions file, the same way you can add arbitrary port forwardings in PuTTY.
Every SSH tunneled port forwardings must be know on the X2Go Server side. This is handled via the X2Go session DB.
On multi-user system you will run into immense troubles, if there isn't $SOMETHING, that is aware of all ports in use.
Also for session resuming, you have to "remember" what SSH port got tunneled to where.
o people on the client-side are required to do additional steps (intalling lpd from the Windows CD e.g.)With any Windows version beyond XP, the lpd is already present on the hard disk, so we could request Admin Permissions and trigger installation - IF we want to print using a local lpd (which is what my solution does, admittedly - but it could be solved differently, without needing a client-side lpd, see below).
Ack. Not feasible for X2Go Client in portable mode.Unix system don't use lpr/lpd by default anymore (only ipp://), so this has to be handled, as well.
Also, as a sysadmin for Linux, I probably don't want lpd listening on my X2Go Client system. A firewall then has to modified for this, as well (because cups-bsd's lpd listens on every IP assigned to a system by default).
o people on the CUPS server have to deal with the client-side printer driversNo. No, they do not. They can use one generic PDF printer driver like CUPS-PDF or CUPS-X2GO. Specifying the printer on the CUPS server is only neccessary if you don't want to go the PDF way (for example, because the CUPS driver for a particular printer has special features that you want to use, which cannot be set by printing to PDF - but that's a problem the current implementation also has, AFAIU).
OK...
I think, that the current concept of remote printing is quite ok in these respects: o create a printable file on the server-side that can be handled by all sorts of clients o print that file on the client with the hardware/printer-drivers of the clientDude, that's exactly what my solution does, too. Only without the kludgy fuse/file sharing requirement inbetween.The only question is: is fuse/sshfs the best way of shoving that printable over to the client...No, no, and no. Use a port forwarding, transfer the PDF as a bitstream, pipe that into a local file on the client, if neccessary (neccessary == your PDF-to-printer tool on the client can't handle a bitstream), convert PDF data to a format suitable for the windows printer driver. SumatraPDF is a GPL'ed PDF viewer that I've been using fo years now, for this exact purpose. Due to the lack of tunneling in X2GoClient, I'm using Redmon to catch the bitstream and convert it to a temporary file. But since both SumatraPDF and X2GoClient are GPL, it should be possible to integrate the relevant parts of SumatraPDF into X2GoClient, at least for the windows build. (For Linux and Mac, I'm assuming that dumping PDF data into the local CUPS will automagically trigger the required steps). That way, we could probably even eliminate the step with the temporary file, and also add compression to further accelerate the transfer of the printjob (I've piped print jobs through gzip, bzip2 and xz before, the speed improvement can be pretty surprising. A PCL print job that would take 6 minutes to transfer went down to 1 minute with bzip2.) So, in short, I'd like to see (== have wishlist bugs for) two things in X2GoClient: 1) An option to be able to add arbitrary portforwardings to a session, like in PuTTY. This would probably be handy for so much more than just printing. 2) An integrated, GPL-based PDF viewer that is stripped down to "grab bitstream, convert it to printable file for the locally installed printer driver".
Please add those wishlist bugs. Lift this discussion to x2go-dev ML and let's get feedback from others. At the end someone has to modify the code as you propose... (and I am not convinced that the gain of this change will be worth the hassle of redesigning the printing stuff completely inside X2Go).
Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
pgpUkNfNUbMIC.pgp
Description: Digitale PGP-Signatur
_______________________________________________ x2go-user mailing list x2go-user@lists.x2go.org http://lists.x2go.org/listinfo/x2go-user
