M8R-udfkkf wrote:

How it looks in adobe reader.

Attached:

From #ghostscript:

<Robin_Watts> hexmode: What are you using to do thumbnailing ? [09:57]
<hexmode> Robin_Watts: gs
<Robin_Watts> hexmode: What version of gs ? [09:58]
<Robin_Watts> Versions of gs prior to 9.00 will not have handled color

profiles correctly, which means you may see slight colour
shifts.  [09:59]

<hexmode> Robin_Watts: I'll double check but the cluster runs Ubuntu Lucid by

default: http://packages.ubuntu.com/lucid/ghostscript

<hexmode> ah, that is prior to 9.00
<hexmode> :)
<hexmode> I'll add that to the bug
<hexmode> and ask ops to upgrade
<Robin_Watts> BUT... I'd consider using mupdf rather than gs.
<Robin_Watts> MuPDF does not handle color profiles either, but for PDF files

with text in, the antialiasing given is MUCH nicer (and faster).
                                                          [10:00]

<Robin_Watts> gs is by far the better choice when running for print output.

[10:01]

<Robin_Watts> mupdf is optimised for screen output, so may be a better bet for

what you need.  [10:02]

<hexmode> I wasn't aware of MuPDF [10:03]
<Robin_Watts> Also, it would be good to see the exact command used by the

wikimedia cluster, because the options used can have a large
effect.

<Robin_Watts> muPDF is from the same company that maintains gs, and is

released under the same license.

<Robin_Watts> That looks a lot like you're rendering to JPEG - the ringing

artifacts etc.  [10:04]

<chrisl> It is a jpeg. [10:09]
<chrisl> hexmode: if you are stuck with the GS 8.x (I think in Lucid) you can

try using the -dUseCIEColor command line option.  [10:11]

<hexmode> chrisl: that's probably the best shot at this point. tyvm [10:12]
<chrisl> hexmode: the "heavily compressed" effect is, as Robin_Watts

mentioned, because it's jpeg compressed - the solution is: don't use
jpeg.....  [10:13]

<hexmode> chrisl: yeah, don't know why they didn't use png
<chrisl> png would be my choice, yes [10:14]

Looks like we are doing

gs -sDEVICE=jpeg -sOutputFile=- -dFirstPage={$page} -dLastPage={$page}

-r{$wgPdfHandlerDpi} -dBATCH -dNOPAUSE -q <sourcefile> | convert -depth 8 -resize ${width} -

We could probably do better (get rid of convert and optimize gs JPEG output a bit)

Created attachment 10531
Rendered with gs 9.05

PDF file rendered with

gs -sDEVICE=jpeg -sOutputFile=after_gs.jpeg -dFirstPage=1 -dLastPage=1 -r150 -dBATCH -dNOPAUSE -q Welcome2WP_English_082310.pdf with GPL Ghostscript 9.05 (2012-02-08)

Attached:

Created attachment 10532
gs 9.05 rendered file processed by convert Version: ImageMagick 6.7.5-7 2012-03-07 Q16

convert -depth 8 -width 422 after_gs.jpeg after_convert.jpeg

Attached:

This issue will get resolved by bug 36623 (upgrade to Precise). We could ask that the image scalers cut in line.

We're now on 9.05 as the error in bug 23652 comment 4 shows.