[X2go-Dev] Printing-related question for Windows X2go client users

John A. Sullivan III jsullivan at opensourcedevel.com
Sat Dec 10 17:39:59 CET 2011


On Sat, 2011-12-10 at 17:28 +0100, Stefan Baur (newsgroups-Kontakt)
wrote:
> 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:
> - 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 
> third-party solution here.
> - 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
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




More information about the x2go-dev mailing list