Re: [groff] gropdf(1) Has Ugly Thick Lines by Default.

[Tadziu Hoffmann]

> 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