On 09-Jul-06 Peter Schaffter wrote: > I've been contemplating adding some macros to the mom set to > ease the creation of simple graphical objects: rules, boxes and > elipses/circles ("ease" meaning "make easier for newcomers to > groff"). > > However, I've discovered something troubling: rules drawn with > > \D'l <co-ordinates>' > > have rounded caps; the ends of the rules are not straight. > > Equally, unfilled polygons drawn with > > \D'p <co-ordinates> > > all have rounded corners, whereas filled polygons drawn with > > \D'P <co-ordinates>' > > produces the expected "sharp" corners.
I hadn't spotted that difference! Good to have it pointed out. > Typographically speaking, this is not an expected, or--in my > experience--justifiable default behaviour for rules and polygons. Agreed. > The effect is scarcely noticeable with narrow rule weights > (i.e. < 1000 units), but when the rule weight increases the effect > becomes more and more pronounced. > > So, the usual questions: > > 1. What is the rational behind groff's drawing rounded caps on > rules, and rounded corners on unfilled polygons? I don't know but I set out some considerations below. > 2. Can this behaviour be changed in user space? Yes. There are raw PostScript commands, 'setlinejoin', 'setlinecap' and 'setmiterlimit' relevant to it (info quoted from the PostScript Language Reference Manual or "Red Book"): \X'ps: exec n setlinejoin' where n=0: Miter join--the outer edges of the strokes for the two segments are extended until they meet at an angle ... If the segments meet at too sharp an angle, a bevel join ["n=2" below] is used instead. This is controlled by the the 'miterlimit' parameter established by 'setmiterlimit' [for which see Red Book] n=1: Round join--a circular arc with diameter equal to the line width is drawn around the point where the segments meet and is filled in, producing a rounded corner. 'stroke' draws a full circle at this point. If path segments shorther than one-half of the line width meet at sharp angles, an unintentional "wrong side" of this circle may appear. n=2: Bevel join--the meeting path segments are finished with butt end caps [as with "n=0" for 'setlinecap' below]; then the resulting notch beyond the ends of the segments is fille with a triangle. \X'ps: exec n setlinecap' where n=0: Butt cap--the stroke is squared off at the endpoint of the path. There is no porjection beyond the end of the path. n=1: Round cap--a senicircular arc with diameter equal to the line width is drawn round the endpoint and filled in. n=2: Projecting square cap--the stroke continues beyond the endpoint of the path for a distance equal to half the line width and is squared off. So for single lines with square ends, you should '0 setlinecap'; I can't think of a good reason for round ends on rules--it may be that this is the PS default (though I can't see this stated in the Red Book). For rules in tables, again '0 setlinecap' normally except where the ends of horizontal and vertical rules meet at right angles, when you need '2 setlinecap' provided the lines are of the same thickness (it may be that this little complication is the reason for rounding the ends of rules. For polygons (filled or unfilled), normally '0 setlinejoin'. This can produce unwanted results with sharp angles and thick lines, but I can't otherwise think of a reason for using round joins as a default nor for unfilled as opposed to filled polygons. The current values of the relevant parameters can be accessed in PS by 'currentlinejoin' and 'currentlinecap' etc. Hoping this helps Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <[EMAIL PROTECTED]> Fax-to-email: +44 (0)870 094 0861 Date: 10-Jul-06 Time: 09:16:11 ------------------------------ XFMail ------------------------------ _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff