[gs-bugs] [Bug 689378] Ghostscript renders bad quality from PDF text. Acrobat gets it right

[bugzilla-daemon at ghostscript.com]

http://bugs.ghostscript.com/show_bug.cgi?id=689378

Ken Sharp <ken.sharp at artifex.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|PDF Interpreter             |Graphics Library
           Platform|PC                          |All
            Version|8.57                        |HEAD
         AssignedTo|ken.sharp at artifex.com       |support at artifex.com
     Ever Confirmed|0                           |1
         OS/Version|Linux                       |All

--- Comment #8 from Ken Sharp <ken.sharp at artifex.com> 2010-08-12 10:07:34 UTC ---
(In reply to comment #5)

> 1. Ghostscript is rendering the fonts less bold than Acrobat Reader when the
> Tr mode is 0 (normal show).

I'm not sure this is entirely true, at least not since we moved to FreeType to
do the rendering ;-) It is true that this happens at low resolution, but if you
zoom out with Acrobat with smoothing turned off the bold font becomes the same
weight as the light font there too.


> 2. Ghostscript charpath is 'fatter' than what results from Acrobat Reader,
> making the characters rendered with Tr 7 much bolder. The difference is evident even
> at 600 dpi, but is very noticeable at 144 dpi.

This seems to be the whole of the problem. Given that it persists across two
different font engines, the problem must be a rendering issue I believe, not
the returned path from the font interpreter.

I modified the PDF file to change the clip text rendering mode to a stroke
mode, and removed the images. Interestingly this produces output very similar
to that produced by Ghostscript with the clipping in place.

I did try changing the line width up and down, in case GS was using the outer
edge of the line instead of the centre, but this made no difference.

So I have to assume its simply a difference in the way that clip is applied to
images. I don't think its the result of charpath, just the way the resulting
path is applied.

I think that makes this Robin's problem so I've assigned it to him, if his
research shows it really is a font/path problem then it can come back. In the
meantime I've updated the component, version and platform fields.

-- 
Configure bugmail: http://bugs.ghostscript.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.