setlinecap and moveto: whose bug?

[jdaw1]

Please see the simple PostScript file
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug.ps
and two output files:
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug_Ghostscript.pdf
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug_Distiller.pdf

They differ. Which is correct?

[Scott Hemphill]

I'd say Distiller has it wrong. The wide line is supposed to have a
butt cap. The Ghostscript output also agrees with my genuine PostScript
printer.

Scott
--
Scott Hemphill hemp...@alumni.caltech.edu
"This isn't flying. This is falling, with style." -- Buzz Lightyear

[ken]

In article <575b9db5-0632-4c5f...@googlegroups.com>,
jdawi...@gmail.com says...

I believe that Distiller is incorrect, and is 'probably' applying an
incorrect optimisation. Your original code is:

144 72 moveto 144 144 2 copy 72 144 curveto
72 144 moveto 144 144 2 copy 144 72 curveto
StrokeCode

Distiller makes a PDF containing:

q 1 0 0 1 144 72 cm 0 0 m
0 72 0 72 -72 72 c
0 72 0 72 0 0 c
S
Q

Whereas Ghostscript (more accurately the Ghostscript pdfwrite device)
produces:

1440 720 m
1440 1440 1440 1440 720 1440 c
720 1440 m
1440 1440 1440 1440 1440 720 c
S

(The pdfwrite device works at 720 dpi by default, so just divide all the
numbers by 10, or remake the file specifying -r72)

The linecap/linejoin styles in both cases are set/reset correctly
matching the original PostScript, so I haven't bothered to put these
her, we can treat the 'StrokeCode' as a simple stroke. However.....

Notice that the intermediate 'moveto' has been lost in the Distiller
produced PDF file, and the two curves have been optimised together by
altering the current matrix. This has the (surprising, perhaps) effect
of causing the left end of the path to be a *join* rather than a cap,
with the result that you get the wrong kind of terminator.

So it looks to me like you've tripped over an unfortunate optimisation
in Distiller which is invalid in your particular case.



Ken

[jdaw1]

On Tuesday, 26 April 2016 08:28:42 UTC+1, ken wrote:
> So it looks to me like you've tripped over an unfortunate optimisation
> in Distiller which is invalid in your particular case.

Your conclusion is more detailed and knowledgeable than I could do; but agrees with my thinking. Distiller trims needless moveto's, and has been over-enthusiastic about it, thereby joining what should be separate sub-paths.

PLRM3, p191:
> moveto establishes a new current point without adding a segment to the current path, thereby beginning a new subpath.

PLRM3, p627:
> [moveto] starts a new subpath of the current path (see Section 4.4, "Path Construction") by setting the current point in the graphics state to the coordinates (x, y) in user space. No new line segments are added to the current path.
> If the previous path operation in the current path was moveto or rmoveto, that point is deleted from the current path and the new moveto point replaces it.

PLRM3, p645, re pathbbox:
> In LanguageLevel 2 or 3, if the current path ends with a moveto operation, the co- ordinates of the moveto are not considered during the computation of the bounding box unless the moveto is the only element of the path.

[jdaw1]

Bug report submitted, with text as follows.

Mac OS X 10.11.4, Distiller 11.0.14 (17/12/2015).

Also reported at
http://groups.google.com/forum/#!topic/comp.lang.postscript/amUp28S-JFM

Please see the simple PostScript file
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug.ps
and two output files:
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug_Ghostscript.pdf
http://www.jdawiseman.com/papers/bugs/20160425_LineCap_bug_Distiller.pdf

... moveto ... curveto ... moveto ... curveto should create a path with two subpaths. The painting of the middle 'ends' should therefore be determined by setlinecap, not by setlinejoin. But iff the second moveto moves to where the first curveto ends, Distiller joins the sub-paths into a single path, the painting of the middle 'end' of which is then determined by setlinejoin rather than setlinecap. This is a bug. Same bug with lineto instead of curveto.

Likely cause is that the Distiller removes a moveto that is to the same place as the currentpoint. Sometimes this optimisation will be good, but it wrongly removes the new-sub-path effect of the moveto.

Ghostscript, correctly, does not join the subpaths.

[Lawrence D’Oliveiro]

On Tuesday, April 26, 2016 at 9:41:55 PM UTC+12, jdaw1 wrote:

> Ghostscript, correctly, does not join the subpaths.

This may be a dumb question, but ...

What does Distiller do for you that Ghostscript does not?

[jdaw1]

Quickie response:

Full implementation of pdfmark.

Better implementation of infill (which, in GS, is very very slow if the path is made by strokepath).

Distiller wrongly pickles settransfer, but that error is necessary for it to appear correctly in Mac Preview.

Better UI.

[jdaw1]

This moveto bug is still present in Distiller XI Pro 11.0.17 (23/06/2016).

And the © notice says “Copyright © 1984-2012 Adobe Systems …”: another oops.

[jdaw1]

Related bug, recently discussed, about caps on zero-length lines:
https://groups.google.com/forum/#!topic/comp.lang.postscript/MmBOgaaIROw

[jdaw1]

The bug about trimming moveto’s is still present in Distiller XI 11.0.18 (01/10/2016).

[jdaw1]

Bug, still present in Distiller XI Pro 11.0.20 (28.03.2017), has been reported in
http://acrobat.uservoice.com/forums/590923-acrobat-for-windows-and-mac/suggestions/19265068-distiller-moveto-the-currentpoint-results-in-a-co

[jdaw1]

On 12 Jan 2018, in the above thread, Adobe replied:
> Thanks for bringing this issue to our notice. we have logged bug in our database for the issue.