Page MenuHomePhabricator

Fix PDF rendering by upgrading image scaler Ghostscript to 9.05+
Closed, ResolvedPublic


Author: M8R-udfkkf

How it looks rendered on the wiki

The pdf file at:

doesn't seem to render properly. The 1st page color is off, and the image looks heavily compressed.

Version: unspecified
Severity: normal


Welcome2WP_English_082310.pdf.png (599×422 px, 257 KB)



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:27 AM
bzimport set Reference to bz36580.
bzimport added a subscriber: Unknown Object (MLST).

M8R-udfkkf wrote:

How it looks in adobe reader.


In_Acrobat.png (589×414 px, 31 KB)

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


<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).

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


<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

<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)


after_gs.jpeg (1×1 px, 155 KB)

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


after_convert.jpeg (599×422 px, 45 KB)

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.

Gilles raised the priority of this task from Medium to Unbreak Now!.Dec 4 2014, 10:25 AM
Gilles added a project: Multimedia.
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Medium.Dec 4 2014, 11:22 AM