PostSCript Reference Manual (psrefman.pdf) suggests on page 506 that the following holds for zero-width lines: linecap 0: nothing is rendered linecap 1: a circle with diameter linewidth is rendered linecap 2: a square with side length linewidth is rendered The first two items meet expectation, but the third item also renders nothing! Unfortunately the Adobe Distiller of Acrobat 11 shows the same bahavior. Still I think it's not matching the reference manual. I have a simple test case: -- /D { M z } bind def /M { moveto } bind def /P { showpage } bind def /z { closepath } bind def /S { stroke } bind def /sC { setlinecap } bind def 2 setlinewidth 0 sC 50 dup D S 1 sC 70 dup D S 2 sC 90 dup D S P -- It should show two small (2pt) dots, a circle and a square, but it just shows the circle.
It's not zero width lines that's the problem. It's the fact that they are zero length lines too. I think gs is doing the right thing here, and given that we are matching distiller (I've verified it with Acrobat Pro 9 too) we'd need really strong evidence to prove we were wrong. So, closing.
I agree that GhostScript is matching the behavior of Distiller. But this is still clearly a bug. 1) It is inconsistent with the treatment of a round cap. 2) It is inconsistent with the PLRM3 description (p.673), which should be canon.
A simple thought experiment. Consider 3 lines with round caps, one horizontal, one vertical, one diagonal. Now shorten those lines gradually. As the line length approaches zero, the appearance of all the lines is identical, and is 'continuous' as we reach zero. Now repeat that experiment with square caps. The diagonal line has a different appearance to the other two. There is no way to offer continuity in the zero line length case. Therefore we opt to do the same as Acrobat.
(In reply to Alan from comment #2) > I agree that GhostScript is matching the behavior of Distiller. But this is > still clearly a bug. I don't believe so. > 1) It is inconsistent with the treatment of a round > cap. The PostScript language is not perfectly consistent, nor are implementations of it. We generally regard Adobe as the reference implementation and we aim to match it. The comment si see in our code suggest that this has been tested with the Adobe CPSI interpreter and our current behaviour matches that. > 2) It is inconsistent with the PLRM3 description (p.673), which should > be canon. The PLRM on that page says *nothing* about zero length strokes. Its defensible either that the caps should be drawn or not. From that POV this is not unambiguous. The fact that Adobe apparently choose to have different behaviour for different caps does not make it wrong merely, as you say, inconsistent. We choose to follow the Adobe implementation where we cna determine what that is, and match it. Since the PostScript language is owned by Adobe, it should be clear the the Adobe implementation of the language is the reference, the canon if you prefer.
Yes, you are quite right. The explanation is actually rather obvious, but it is in the PDF manual: "If a subpath is degenerate (consists of a single-point closed path or of two or more points at the same coordinates), the S operator shall paint it only if round line caps have been specified, producing a filled circle centered at the single point. If butt or projecting square line caps have been specified, S shall produce no output, because the orientation of the caps would be indeterminate." Sorry for the noise.