Last modified: 2012-10-26 20:58:07 UTC
Created attachment 10524 [details] How it looks rendered on the wiki The pdf file at: https://commons.wikimedia.org/wiki/File:Welcome2WP_English_082310.pdf doesn't seem to render properly. The 1st page color is off, and the image looks heavily compressed.
Created attachment 10525 [details] How it looks in adobe reader.
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 [details] 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)
Created attachment 10532 [details] 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
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.
