Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2541 > unrolled thread

setlinecap and moveto: whose bug?

Back to article view | Back to comp.lang.postscript

Contents

  setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-04-25 15:59 -0700
    Re: setlinecap and moveto: whose bug? Scott Hemphill <hemphill@hemphills.net> - 2016-04-25 19:51 -0400
    Re: setlinecap and moveto: whose bug? ken <ken@spamcop.net> - 2016-04-26 08:28 +0100
      Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-04-26 01:31 -0700
      Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-04-26 02:41 -0700
        Re: setlinecap and moveto: whose bug? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-01 19:55 -0700
          Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-06-02 06:44 -0700
    Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-07-17 14:51 -0700
      Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-07-28 03:01 -0700
        Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2016-10-11 15:23 -0700
          Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2017-05-12 17:25 -0700
            Re: setlinecap and moveto: whose bug? jdaw1 <jdawiseman@gmail.com> - 2018-01-17 15:11 -0800

#2541 — setlinecap and moveto: whose bug?

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? 

[toc] | [next] | [standalone]

#2542

jdaw1 <jdawiseman@gmail.com> writes:

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

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	hemphill@alumni.caltech.edu
"This isn't flying.  This is falling, with style."  -- Buzz Lightyear

[toc] | [prev] | [next] | [standalone]

#2543

In article <575b9db5-0632-4c5f-9bb3-a54a56fd929a@googlegroups.com>, 
jdawiseman@gmail.com says...
> 
> 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? 

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

[toc] | [prev] | [next] | [standalone]

#2544

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.

[toc] | [prev] | [next] | [standalone]

#2545

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.

[toc] | [prev] | [next] | [standalone]

#2601

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?

[toc] | [prev] | [next] | [standalone]

#2607

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. 

[toc] | [prev] | [next] | [standalone]

#2707

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.

[toc] | [prev] | [next] | [standalone]

#2709

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

[toc] | [prev] | [next] | [standalone]

#2876

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

[toc] | [prev] | [next] | [standalone]

#3065

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 

[toc] | [prev] | [next] | [standalone]

#3213

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.postscript

csiph-web