Bug 691118 - PDF file mis-rendered
Summary: PDF file mis-rendered
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Interpreter (show other bugs)
Version: master
Hardware: All All
: P2 normal
Assignee: Robin Watts
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-18 09:07 UTC by Marcos H. Woehrmann
Modified: 2012-04-12 17:13 UTC (History)
1 user (show)

See Also:
Customer: 330
Word Size: ---


Attachments
clipped_m_4.pdf (175.78 KB, application/pdf)
2010-02-18 09:08 UTC, Marcos H. Woehrmann
Details
Simplified sample file. (2.16 KB, application/pdf)
2010-02-18 10:32 UTC, Alex Cherepanov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2010-02-18 09:07:35 UTC
The attached PDF file is mis-rendered by the various versions of Ghostscript I tested (including head, 
r10761).  In particular the upper right portion of the shape has a "bite" taken out of it.  Adobe Acrobat 
9.3.0 and Apple Preview 5.0.1 (503) render the file correctly.

The command line I'm using for testing:

  bin/gs -sDEVICE=ppmraw -o test.ppm ./clipped_m_4.pdf
Comment 1 Marcos H. Woehrmann 2010-02-18 09:08:35 UTC
Created attachment 5965 [details]
clipped_m_4.pdf

This file is a small portion of the customer supplied file, as such I do not
believe it needs to be marked private.
Comment 2 Ray Johnston 2010-02-18 09:57:21 UTC
If this is a shading issue, please reassign to Michael Vrhel.

The 'm' shape is a clip path and is filled with:

q
/Perceptual ri
/GS0 gs
%Resolving: [17 0]
1182.33423 0 0 -1182.33423 483.75293 693.801758 cm
BX
/Sh0 sh
%Resolving: [20 0]
%Resolving: [19 0]
%Resolving: [18 0]
%Function: << /Bounds [] /Functions [<< /C1 [1.0] /C0 [0.0] /Domain [0.0 1.0]
/FunctionType 2 /N 1.0 >>] /Encode [0.0 1.0] /FunctionType 3 /
Domain [0.0 1.0] >>
%Resolving: [16 0]
%Resolving: [12 0]
<<
/Domain [
0.0 1.0 ]
/Filter /FlateDecode /FunctionType 4 /Length 91 /Range [ 
0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0 ]
>>
stream
%FilePosition: 2588
endobj
%Function: << /Filter /FlateDecode /Length 91 /Function {1.0 2 1 --roll-- 1.0 2
1 --roll-- 1.0 2 1 --roll-- 0 --index-- 1.0 --cvr-- --exch-- --sub-- 2 1
--roll-- 5 -1 --roll-- 1.0 --cvr-- --exch-- --sub-- 5 1 --roll-- 4 -1 --roll--
1.0 --cvr-- --exch-- --sub-- 4 1 --roll-- 3 -1 --roll-- 1.0 --cvr-- --exch--
--sub-- 3 1 --roll-- 2 -1 --roll-- 1.0 --cvr-- --exch-- --sub-- 2 1 --roll--
--pop--} /FunctionType 4 /File -file- /FilePosition 2588 /Domain [0.0 1.0]
/Range [0.0 1.0 0.0 1.0 0.0 1.0 0.0 1.0] >>
%Resolving: [15 0]
EX
Q
Comment 3 Alex Cherepanov 2010-02-18 10:32:53 UTC
Created attachment 5966 [details]
Simplified sample file.

This is a regression. v.8.57 renders the file fine, v.8.60 has the same problem
as the HEAD.
Comment 4 Alex Cherepanov 2010-02-18 14:55:04 UTC
r7982 | leonardo | 2007-05-16 17:04:35 -0400 (Wed, 16 May 2007) | 22 lines
Fix (shadings) : Shorten a radial shading when it is larger than paint area.

DETAILS :
This partially improves performance for the test case of
the bug 689189 "PDF fails with /unregistered in --shfill--".

The test case includes multiple radial shadings,
which are 100+ times larger than the path bbox.
This patch replaces such shadings with a smaller shading,
which paints the bbox with same color
(a minor color difference is possible due to rounding errors).
Comment 5 Robin Watts 2011-06-06 21:10:02 UTC
Fixed in:

commit f92a542b0475a12f4724d3e57f232cafbe17ce50
Author: Robin Watts <Robin.Watts@artifex.com>
Date:   Mon Jun 6 21:00:41 2011 +0100

    Bug 691118: Fix radial shading bug

    Bug 691118 describes a bug with radial shadings in a PDF file.

    Back in r7982 (git 69a43b0) (16 May 2007) Igor introduced some cunning
    code to speed radial shadings. It would spot that the shading was large
    in comparison with the area being filled, and produce a smaller,
    equivalent shading.

    Essentially, it would take the destination rectangle, and figure out
    where in the shading the 'extremes' of that rectangle would come from
    (allowing for distortion in shape generation) and ensure that the newly
    generated shading covered the same area.

    Either the corners of the rectangle could be extremes, or points on the
    side. The code for the points on the sides was broken due to a typo
    causing the X and Y cases to be switched.

    All that is required to solve the bug is to change the == to !=.

    In researching the problem however, I recommented lots of the code to
    make it more comprehensible (to me at least!) along with introducing
    some temporary variables to make it clearer and avoid needless
    recomputation of values. I am committing this as I believe it's a step
    forward for the code, even though it doesn't actually make a
    difference.

    48 differences in non-pdfwrite/ps2write tests. 11 in pdfwrite, 17 in
    ps2write. Checked with bmpcmp, all unnoticable to the naked eye, so
    presumably progressions.