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

[Stefan Baur (newsgroups-Kontakt)]

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.

Kind Regards,
Stefan