> It seems odd to subtract 0.25 before rounding to the nearest integer > rather than 0.5, but perhaps it's accomodating the transform?
This appears to be a trick to prevent line widths of horizontal and vertical lines from growing in 2-pixel increments in the final raster image when slowly increasing the line width in the Postscript program. If the endpoints are snapped to the pixel centers, then line widths will grow symmetrically on both sides, giving lines of 1, 3, 5, ... pixels width. When snapping to an offset of 1/4 of a pixel from the pixel center, the line width will grow alternating on both sides, giving widths of 1, 2, 3, 4, ... pixels. An offset of 1/2 would give line widths of 2, 4, 6, ... pixels, which is again not useful. Of course snapping does not really make sense when converting from Postscript to PDF, but it is useful when creating a raster image. Apparently it is nevertheless done by ghostscript regardless of output device. If you use "ps2pdf -r7200 ...", you will see that the coordinates have an additional digit of precision (the default appears to be 720 in the version of ghostscript on my machine) and the offset is only 1/10 as large. > You mentioned switching from `s' to `S' to `closepath' the > line. How does closing the path affect the rendering of a > simple straight line that's not a `circuit'? s = closepath stroke S = stroke If you close the line, it does not have linecaps anymore, but only linejoins. This can make a difference in the appearance of the rendered line depending on the current settings of linecap and linejoin (see attached PDF for illustration). Unless the path is really supposed to be closed (which in this case it isn't) "S" is the correct operator.
linejoin.pdf
Description: Adobe PDF document
