John A. Sullivan III wrote:
On Sat, 2011-12-10 at 14:36 +0100, Stefan Baur (newsgroups-Kontakt) wrote:
Hi list,
this question goes out to all the Windows users of the X2go-Client:
Has anybody ever tried to use "Sumatra PDF" as a PDF endpoint on the Windows client, instead of Adobe Reader? <snip> It looks very interesting and we'd be interested in trying it. However, PDFs have been a real sore spot in our VDI work and our offering both Linux and Windows desktops for those who would like to leave the Windows world for any of several reasons. Not only is there nothing even close to Acrobat for editing PDFs in the open source world, the readers also have serious shortcomings.
<further "PDF/Adobe sucks but we'll just have to deal with it" rant, *that I can fully relate to*, snipped>
I can see why one would not want to use a non-Adobe PDF viewer as regular PDF viewer, given the numerous extensions to the original PDF spec that may or may not be supported by such a third-party client, but my intent here was to (ab)use Sumatra PDF for printing via the Windows X2go client *only*.
I am *not* suggesting replacing the default PDF viewer on the client computers, nor on the host (which wouldn't work with Sumatra PDF anyway, as it is a Windows-only application).
The reasoning why I'd prefer printing via a PDF transferred to the client is the following: third-party solution here.
- Linux and Mac OS are Postscript-centered when it comes to printing, and whoever is running a Linux client usually also knows what printer to buy (i.e. one with Postscript or PCL support). So there is no need for a
- In the world of Microsoft Windows, however, such nasties as "GDI-only printers" exist. These are usually low-priced printers that cannot be made to work with Linux or Mac OS.
Converting a Postscript printjob into a PDF is easy, though (that's what CUPS does when you install the virtual PDF printer) - and passing the resulting PDF file to a viewer like Sumatra PDF that automatically starts to dump it into the proper printer queue on the client means: We have a printing solution that does *not* require some sort of Linux driver for the printer, letting us use all the fancy features the printer may have that are supported by its Windows driver (think duplexing or different paper trays/outbins - these are usually a pain in the behind to get to work when all you have is a generic PCL-something PPD, or color profiles).
My general assumption behind this is that if you try to print a PDF from Adobe Reader for Linux on the host, it will be converted into Postscript first, then into whatever printer-specific language that may be required: usually PCL 3, PCL5, PCL 6 - or back into PDF.
This conversion from PDF to PS and again into PDF with CUPS is, from my experience, *not* a 1:1 mapping/translation, so the resulting PDF should be a "basic" PDF type with all the trouble-causing fanciness removed (and usually resulting in a significantly larger spool file).
Of course, it's been at least three years, if not more, since I last had to deal with conversion of printing formats, so, If I'm wrong here and my knowledge is outdated, or your experience proves me wrong, please feel free to correct me.
Also, to quote from Sumatra PDF's Wikipedia entry:
It has a 4.4 MB setup file, compared to Adobe Reader's 40.5 MB, for Windows 7. Installed size is 8.4 MB, whereas Adobe Reader requires 335 MB of available disk space. ==>so I wouldn't see disk space/size/bloat issues.
Plus, since it is open source, it might even be possible to integrate the relevant parts of its code into the X2go client itself - any of the coders willing to comment on the feasibility of that? If that works, the end user wouldn't even get to see a second PDF viewer program, as it would become part of the X2go client's code.
Kind Regards, Stefan