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.
-Stefan