RE: [Groff] Rules drawn with \D are rounded

[Ted Harding]

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) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 10-Jul-06                                       Time: 09:16:11
------------------------------ XFMail ------------------------------