[gs-bugs] [Bug 698662] - Ghostscript - Stripes of content shifted horizontally in rendered output

[b***@artifex.com]

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

Bug ID: 698662
Summary: Stripes of content shifted horizontally in rendered
output
Product: Ghostscript
Version: master
Hardware: PC
OS: Windows 7
Status: UNCONFIRMED
Severity: normal
Priority: P4
Component: Graphics Library
Assignee: ghostpdl-***@artifex.com
Reporter: ***@artifex.com
QA Contact: gs-***@ghostscript.com
Word Size: ---

The customer reports that the file (supplied by email, please see the support
email list) Test_Baume.pdf does not render correctly.

The customer command line is:

gs -dNOPAUSE -dBATCH -r300 -sDEVICE=tiffg4 -o 300.tif -dBufferSpace=200000000
Test_Baeume.pdf

However I find that the effect occurs running to the display device, even at
comparatively low resolutions (72 dpi). To get correct output I had to render
it at 40 dpi.

It appears that horizontal strips of the output have (some of) the content
misplaced. So I believe this is most likely a clist problem.

The file is not attached as the customer has requested that it not be made
puclicly available.

[b***@artifex.com]

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

Ken Sharp <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Customer| |870
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1
Priority|P4 |P2
Assignee|ghostpdl-***@artifex.com |***@artifex.com

--- Comment #1 from Ken Sharp <***@artifex.com> ---
P2 for customer problem, assigning to Ray in the first instance as this looks
like a clist problem.

[b***@artifex.com]

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

Ray Johnston <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |IN_PROGRESS

--- Comment #2 from Ray Johnston <***@artifex.com> ---
I've managed to reduce the file to one with no transparency that shows the
problem with 8 path painting operations (I may reduce it further if debug
proves it necessary).

[b***@artifex.com]

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

--- Comment #3 from Ray Johnston <***@artifex.com> ---
Actually reduced it to a single path containing two curves :-0
q 1 0 0 1 1615 1463.3 cm
0 0 m
0 0 0.3 0.3 0.3 0.3 c
0.3 0.3 0 0 0 0 c
S
Q

The clist playback -ZP trace shows:
[P]Path before reducing:
% state_flags=7 subpaths=1, curves=2, point=(3365.832031,1918.457031)
% box=(3364.582031,1917.832031),(3365.832031,1918.457031) last=
% segments= (refct=1, first=, current=)
3364.5820 1918.4570 moveto % <,>:0 #curves=2 last=
3364.5820 1918.4570 3365.2070 1917.8320 3365.2070 1917.8320 curveto %
<,>:0
3365.2070 1917.8320 3365.8320 1918.4570 3365.8320 1918.4570 curveto %
<,>:0

and the non-clist path debug shows:
[P]Path before reducing:
% state_flags=7 subpaths=1, curves=2, point=(3364.582031,1918.457031)
% box=(3364.582031,1917.832031),(3365.207031,1918.457031) last=
% segments= (refct=1, first=, current=)
3364.5820 1918.4570 moveto % <,>:0 #curves=2 last=
3364.5820 1918.4570 3365.2070 1917.8320 3365.2070 1917.8320 curveto %
<,>:0
3365.2070 1917.8320 3364.5820 1918.4570 3364.5820 1918.4570 curveto %
<,>:0

the difference is in the last line 3365.8320 should be 3364.5820

Using -ZL I see writing:
1 0 0 1 1615 1463.3 cm
0 0 m
0 0 0.3 0.3 0.3 0.3 c
[P] 3364.5820 1918.4570 moveto % 0xe7c7d990<0x0,0x0>:0 #curves=0
last=0xe7c7d990
[P] 3364.5820 1918.4570 3365.2070 1917.8320 3365.2070 1917.8320 curveto %
0xe7c7dc00<0xe7c7d990,0x0>:0
0.3 0.3 0 0 0 0 c
[P] 3365.2070 1917.8320 3364.5820 1918.4570 3364.5820 1918.4570 curveto %
0xe7c7dc48<0xe7c7dc00,0x0>:0
S
[L]band 0: size=8, left=0, id=1 , set_misc2(8)
[L]band 0: size=14, left=0, to id=1 , offset=8, set_ctm(14)
[L]band 0: size=1, left=0, to id=1 , offset=22, begin_clip(1)
[L]band 0: size=7, left=0, to id=1 , offset=23, fill_rect 0(7)
r6:0,7022,0,4967
[L]band 0: size=1, left=0, to id=1 , offset=30, end_clip(1)
[L]band 0: size=13, left=0, to id=1 , offset=31, put_params(13)
[p]initial (0,0), clip [1909..1927)
[L] rmoveto:0: 3364.58 1918.46
[L]band 0: size=7, left=0, to id=1 , offset=44, rmoveto(7)
[p]moveto (3364.58,1918.46)
[p]curveto (3364.58,1918.46; 3365.21,1917.83; 3365.21,1917.83) side 0
[L] hqcurveto:0: 0 -0.625
[L]band 0: size=6, left=0, to id=1 , offset=51, hqcurveto(6)
[p]curveto (3365.21,1917.83; 3364.58,1918.46; 3364.58,1918.46) side 0
[L] scurveto:0:
[L]band 0: size=1, left=0, to id=1 , offset=57, scurveto(1)
[p]final (3364,1918)

but during rendering:
[L]set_ctm(offset=27): [2.08333 0 0 -2.08333 3364.58 1918.46]
[L]begin_clip(offset=41):
[L]fill_rect 0(offset=42): x=0 y=0 w=7022 h=4967
[L]end_clip(offset=49):
[L]put_params(offset=50): cmd_opv_ext_put_drawing_color
[L]rmoveto(offset=63): (0,0) 3364.58 1918.46
[L]hqcurveto(offset=70): 0 -0.625
[P] 3364.5820 1918.4570 moveto % 0xe7c88ff0<0x0,0x0>:0 #curves=0
last=0xe7c88ff0
[P] 3364.5820 1918.4570 3365.2070 1917.8320 3365.2070 1917.8320 curveto %
0xe7c89068<0xe7c88ff0,0x0>:0
[L]scurveto(offset=76):
[P] 3365.2070 1917.8320 3365.8320 1918.4570 3365.8320 1918.4570 curveto %
0xe7c890b0<0xe7c89068,0x0>:0
[L]stroke(offset=77):

It seems that the scurveto that had the correct coordinates during writing
didn't lead to the reader having the correct coordinate for X (should be
3364.58).

Note this is the first difference, but there may be other instances of this
pattern in the file causing similar displacements. It is clear that this
PDF creator uses specific sequences for paths.

Creator: MicroStation 8.11.9.459 by Bentley Systems, Incorporated
Producer: Adobe PDF Library 9.0

[b***@artifex.com]

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

Ray Johnston <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |FIXED

--- Comment #4 from Ray Johnston <***@artifex.com> ---
Fixed by commit d3280ae0f8306d3c2a5d3d8efd10b4bc72088d21

The scurveto clist path reading logic assumed that if the first value
A, was 0, the previous curve entry was vertical, but the writing logic
checked for B == 0 and decided to use h*curveto, so if A was also 0,
the reading logic would assume vertical

[b***@artifex.com]

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

Ray Johnston <***@artifex.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |NOTIFIED

[b***@artifex.com]

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

--- Comment #5 from Ray Johnston <***@artifex.com> ---
Actually, the commit was not pushed to origin and other commits intervened.

The actual fix on origin is commit ac241e31c931858e562dc0a4cd88db31e012c2cf