The attached PostScript file from the cairo test suite does not render the miter
in the lower left corner correctly. The miter has been chopped off making it
look more like a bevel join.
Also attached are the reference image from the cairo test suite showing the
miter correctly rendered and the image from Ghostscript showing the incorrect
The PS file prints correctly on my LaserJet 4050.
Created attachment 4435 [details]
The PostScript file
The PostScript file.
Created attachment 4436 [details]
The correct rendering of the PostScript file
Created attachment 4437 [details]
The output from Ghostscript
This is a matter of fixed point underflow that happen at gxstroke.c:730
at 84 dpi and lower. There are other underflows but at 169 dpi or higher the
rendering is close to the correct one.
The sample file can be simplified to
100000 setmiterlimit 10 setlinewidth
[0.001 0 0 -1 0 100] concat
10000 60 moveto 40000 60 lineto 10000 80 lineto stroke
I'm not sure that the "correct rendering" is correct. Opening the PostScript file in Photoshop CS3 produces
the same results as Ghostscript, as does printing the file on an an HP LaserJet P3005.
Created attachment 4439 [details]
Reassigning path and fill problems to Robin Watts.
> This is a matter of fixed point underflow that happen at gxstroke.c:730
> at 84 dpi and lower. There are other underflows but at 169 dpi or higher the
> rendering is close to the correct one.
Looking back in the SVN history, this line is here:
726 : * direction that corresponds to counter-
727 : * clockwise in device space.
728 : */
729 : pl.e.cdelta.x = (fixed) (dpt.x * xx);
730 : pl.e.cdelta.y = (fixed) (dpt.y * yy);
731 : if (orient != orient_portrait)
732 : pl.e.cdelta.x += (fixed) (dpt.y * yx),
733 : pl.e.cdelta.y += (fixed) (dpt.x * xy);
i.e. the cdelta values become so low that using them as directions in the
mitering code means they look parallel, and so we don't mitre.
I have a fix that spots the deltas being small (sum of absolute lengths < an
arbitrary value (16 currently)) and moving to use the floating point 'vector'
stuff for directionality instead.
Created attachment 5729 [details]
Proposed patch to solve the problem.
Fixed in revision 10425 using the attached patch.