[X2Go-User] x2go client side printing

[Mike Gabriel]

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 drivers
>
> No.  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 client
>
> Dude, 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.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.x2go.org/pipermail/x2go-user/attachments/20150110/f93d2ce7/attachment-0001.pgp>