On Thu, 2012-03-08 at 17:31 +0100, Mike Gabriel wrote:

Hi Helmer,

On Do 08 Mär 2012 16:26:31 CET Helmer Teles wrote:

...

Steps to correct it:

I've changed the line in /usr/lib/cups/backend/cups-x2go to:

# PS2PDF command my $ps2pdf = "/usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH - dSAFER -sDEVICE=pdfwrite -sOutputFile=\"%s.pdf\"
-dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode - dPDFSETTINGS=/printer -dDoNumCopies -c .setpdfwrite -f \"%s\"";

FROM:

# PS2PDF command my $ps2pdf = "/usr/bin/gs -q -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH - dSAFER -sDEVICE=pdfwrite -sOutputFile=\"%s.pdf\"
-dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode - dPDFSETTINGS=/prepress -c .setpdfwrite -f \"%s\"";

Patch applied, thanks! http://code.x2go.org/gitweb?p=cups-x2go.git;a=commitdiff;h=86e725ac8e514d40a...

<snip> I do not know much about ghostscript but do we know what this change does and what the real problem was? Was it the PDFSETTINGS=/printer or the DoNumCopies? What does the change really do?

A half hour of Internet research didn't turn up much: -dPDFSETTINGS=/screen (screen-view-only quality, 72 dpi images) -dPDFSETTINGS=/ebook (low quality, 150 dpi images) -dPDFSETTINGS=/printer (high quality, 300 dpi images) -dPDFSETTINGS=/prepress (high quality, color preserving, 300 dpi imgs) -dPDFSETTINGS=/default (almost identical to /screen)

I do not know what color preserving means. I am a little concerned about size. We have had some issues where the wrong settings is the difference between sending a 2MB file and a 40MB file (I don't recall the exact number but I believe the difference was much greater) which can be critical when printing across a WAN. This is from the CutePDF FAQ: How to reduce the size of output PDF file? You can alter the parameters used in a text file "%Program Files%\Acro Software\CutePDF Writer\PDFWrite.rsp". The key parameters are in the line: -dPDFSETTINGS=configuration where configuration can be /screen, /printer, /prepress, /default. Using /Printer can cut size by half.

Thanks - John

On Thu, 2012-03-08 at 18:19 +0100, Mike Gabriel wrote: <snip>

Thanks for your critical feedback. I have only applied the DoNumCopies
setting, the PDFSETTINGS=prepress I have left untouched.

I will build a package of the latest commit and Helmer has to test. Ok Helmer?

Mike <snip> Thanks, Mike - John

On Thu, 2012-03-08 at 19:25 +0100, newsgroups.mail2@stefanbaur.de wrote:

Am 08.03.2012 18:07, schrieb John A. Sullivan III:

...

<snip> I do not know much about ghostscript but do we know what this change does and what the real problem was? Was it the PDFSETTINGS=/printer or the DoNumCopies? What does the change really do?

A half hour of Internet research didn't turn up much: -dPDFSETTINGS=/screen (screen-view-only quality, 72 dpi images) -dPDFSETTINGS=/ebook (low quality, 150 dpi images) -dPDFSETTINGS=/printer (high quality, 300 dpi images) -dPDFSETTINGS=/prepress (high quality, color preserving, 300 dpi imgs) -dPDFSETTINGS=/default (almost identical to /screen)

I do not know what color preserving means. <snip>

It's been a while since I worked in printing support and had to deal with PostScript/PDF/ghostscript stuff, but I'd wager a guess that /prepress is for professional printing, and "color preserving" in that context probably means that ghostscript should not attempt to apply a color profile when processing the file, as professional printing equipment usually has its own methods of color calibration.

Does that sound like it makes sense? ;-)

<snip> Yes, that's what I was guessing more or less and why I was a little concerned about the patch despite my ignorance. I'm guessing the magic is removing DoNumCopies but that seems quite counter-intuitive. I'm wondering if there is a bug in gs for Windows or whatever is generating the file and making this change is accommodating a bug at who knows what expense.

If I recall correctly, we did have some problems printing from Windows TS and I believe it had to do with the file being processed through ps2pdf or some other utility twice. We solved it by making the X2Go printers in TS raw printers and that seemed to work (except in the odd case where the application directly queries the printer for its capabilities). Thanks - John

On Thu, 2012-03-08 at 21:56 +0100, newsgroups.mail2@stefanbaur.de wrote:

Am 08.03.2012 20:25, schrieb John A. Sullivan III:

...

I'm guessing the magic is removing DoNumCopies but that seems quite counter-intuitive.

Uh, no, the patch is to add that option, not to remove it.

Helmer's posting contained the patched version above the original.

<snip> Argh! That should teach me to fly through emails while busy! Thanks - John