Stefan Baur | 20 Feb 11:55 2013

Re: fuse and X2Go printing

Am 20.02.2013 11:31, schrieb Oleksandr Shneyder:
> Simply redirect the ports is no solution
> for X2Go connections over Internet. The job should be converted in PDF
> on server or it will be just too big.

Fine, then do that on the server and after that *stream the PDF data 
stream* to the client. That's what the cups-pdf package does when you 
specify a socket or lpr instead of a file URI, so it's technically possible.

You might not know it, but there are printers that accept PDF natively 
via LPR or port 9100 (some Lexmark models, for example) just like most 
modern printers do with PCL or even Postscript.

So my way to drive them is cups-PDF generic ppd -> socket URI -> Printer.

And for the printers that don't natively speak PDF: a client-side CUPS 
that's already there because the user uses it for everyday print jobs 
will know how to handle a PDF data stream, and when there's no 
client-side CUPS (Windows), you can run a netcat-like listener and 
either print using a PDF tool or prompt the user to save to a file.

> So as result we will have a PDF
> File on server and it not a problem it all to download it to client
> system.

Yes, it is a problem.  Sorry, but it is a horrible design decision to 
convert data back and forth, causing disk IO and CPU cycles when there's 
no good reason to do so.

And it could happens, that on client system you have no printers
> or printer system installed at all. So you can just save a print job as
> PDF-file.

That works just as well with a netcat-like listener.  Simply tell the 
program to pop up a "save as" box when there's no PDF tool (which should 
be user-definable anyways, as some may prefer Adobe, others may prefer 
F/LOSS PDF tools) specified in its settings.