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?
It seems rather interesting, as it is GNU licensed, offers commandline options to print a file to the default printer (or show a print dialog) and auto-terminate itself after printing has finished (look for "Command-line arguments" in the online manual linked below).
Info in English: http://en.wikipedia.org/wiki/Sumatra_PDF http://blog.kowalczyk.info/software/sumatrapdf/manual.html
Info in German: http://de.wikipedia.org/wiki/Sumatra_PDF http://blog.kowalczyk.info/software/sumatrapdf/manual-de.html
I'd love to try it out myself, but I haven't managed to get printing/showing a PDF on the Client to work at all so far, thus testing Sumatra PDF doesn't really make sense on my client yet.
So here's to crowdsourcing - anybody ever tried it, anybody with a working client printer setup willing to try?
Kind Regards, Stefan
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?
It seems rather interesting, as it is GNU licensed, offers commandline options to print a file to the default printer (or show a print dialog) and auto-terminate itself after printing has finished (look for "Command-line arguments" in the online manual linked below).
Info in English: http://en.wikipedia.org/wiki/Sumatra_PDF http://blog.kowalczyk.info/software/sumatrapdf/manual.html
Info in German: http://de.wikipedia.org/wiki/Sumatra_PDF http://blog.kowalczyk.info/software/sumatrapdf/manual-de.html
I'd love to try it out myself, but I haven't managed to get printing/showing a PDF on the Client to work at all so far, thus testing Sumatra PDF doesn't really make sense on my client yet.
So here's to crowdsourcing - anybody ever tried it, anybody with a working client printer setup willing to try? <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.
Believe me, I am no Adobe fan and wish things were different. One of our clients is a construction company who handle very large numbers of very large PDFs - their construction drawings. Last we tested, there were serious bugs in every single non-Adobe PDF reader on Linux which refused to properly print the larger drawings. They always shrunk them to the default paper size.
Moreover and more to the point at hand, none of the open source PDF readers were able to support all the features we frequently encountered among these and other documents. If the reader only handles 85% of documents and has trouble printing, one is required to keep the Acrobat Reader around. Most of our users would prefer to not deal with two applications. I suspect that Sumatra, being lightweight by design, will fall into the same category.
Not that Acrobat Reader is not without problems. Besides its bloat, the Linux reader has hard coded the permissions of set files to 644 wreaking havoc on our shared directories where everything is setgid with a 770 umask so that shared documents can be edited by the group.
So, the point of it all is that I suspect there will be problems using Sumatra - John
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
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. <snip> I admit I just scanned through your response (deadlines :( ) but I think
On Sat, 2011-12-10 at 17:28 +0100, Stefan Baur (newsgroups-Kontakt) wrote: that is the way X2Go printing is working. The x2go cups driver is converting to pdf and sending the pdf to the client. In the Linux and Mac clients, we can print directly to the printer but, in the Windows client, it always opens the default PDF reader no matter which printer one chooses. That's why I assumed you were talking about replacing Acrobat as the default PDF reader, i.e., because as far as I know, that's what the x2go client prints to - the default PDF reader - John
John A. Sullivan III wrote:
<snip> I admit I just scanned through your response (deadlines :( ) but I think that is the way X2Go printing is working. The x2go cups driver is converting to pdf and sending the pdf to the client. In the Linux and Mac clients, we can print directly to the printer but, in the Windows client, it always opens the default PDF reader no matter which printer one chooses. That's why I assumed you were talking about replacing Acrobat as the default PDF reader, i.e., because as far as I know, that's what the x2go client prints to - the default PDF reader - John
Nope, the Windows X2go client offers an option where you can specify a print command and optional parameters - kind of like the print dialog in Adobe Reader for Linux does (like, if you want to bypass the default print environment and use rlpr, for example).
Kind Regards, Stefan
Am 10.12.2011 17:28, schrieb Stefan Baur:
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).
To further back up my own claim here: "Following the reconversion from PDF to PostScript, the file /tmp/colorcir.ps does not match the original file /usr/share/doc/packages/ghostscript/examples/colorcir.ps. However, there should be no visible difference in the printout.", quoted from <http://www.novell.com/documentation/suse91/suselinux-adminguide/html/ch06s06.html#sec:d.ghostscript.postscript>
-
John A. Sullivan III -
Stefan Baur -
Stefan Baur (newsgroups-Kontakt)