IMO it shoulkd be 1 pixel width, but GS render them some wider, because stroking a flattened path gives overlapped strokes. Due to that arcs look some ugly.
Please attach a test case and command line (resolution settings, device, etc.) that demonstrate the problem. Without a test case this bug will be closed.
I'll create and attach a test case when I have time for that. Now I'm busy with P2 bugs. The absence of a test case for an internal bug isn't a good reason for closing by Support.
Here is a test case : 0 setlinewidth 288.2 288.3 10 0 360 arc stroke showpage It gives width glitches with ppmraw with resolutions 72, 100, 200, 300 dpi. Glitch position depends on resolution.
I'm starting to investigate this now. The minimal testcase I can come up with is to start ghostscript with a resolution of 72, and execute the following command: gswin32c.exe -r72 GPL Ghostscript SVN PRE-RELEASE 8.71 (2009-08-01) Copyright (C) 2009 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>0 setlinewidth 288.2 288.3 10 135 180 arc stroke showpage This produces the following pattern: x x xx x x x x Internally, this equates to the gx_default_draw_thin_line function being asked to draw 2 lines. The first from 71969,75615 to 71414,74784, the second from 71414,74784 to 71217 73805. The two separate commands: 0 setlinewidth 288.2 288.3 10 157.5 180 arc stroke showpage and 0 setlinewidth 288.2 288.3 10 135 157.5 arc stroke showpage each produce one of the two thin lines. The problem appears to be that the horizontal/vertical tests at the top of gx_default_thin_line are incorrect. If those special cases are removed, the graphical glitches go away. Continuing to investigate.
The tests at the top of gx_default_draw_thin_line basically check to see if the line is entirely contained within a single row/column of output pixels. If it is, then we plot the entire range of pixels that the line touches in one rectangle plot operation. This differs from what the code does further below, where the trapeziod plotting checks for the centre of the pixel being covered. The fix for this is simple; to check whether the left/right edges of horizontal lines (or the top/bottom edges of vertical lines) actually cross the pixel centre. I have a patch for this locally that I am testing. It needs some additional tweaks to work in a consistent way with my proposed fix for bug 687721.
Created attachment 5448 [details] Proposed patch This patch solves the horizontal/vertical lines being too long. There is a #define in the patch (currently enabled) that also applies the bugfix for 687721. This can be enabled/disabled to view the operation of this patch independent of the fix for that bug.
Reassigning path and fill problems to Robin Watts.
Broken special cases (see comment #5) removed in revision 10391. Replacement special cases added in revision 10392. This fixes this bug.