Re: geometric primitives (was: interviews with groff developers)

[James K. Lowden]

On Mon, 7 Aug 2023 10:44:44 -0500
"G. Branden Robinson" <g.branden.robinson@gmail.com> wrote:

> But groff does support "boxes", if you will.

Cunnigham's Law strikes again!   

>      \D'p h1 v1 ... hn vn'
>           Draw polygon with vertices at drawing position and each
> point in sequence.  GNU troff closes the polygon by drawing a line
>           from (hn, vn) back to the initial drawing position.
>           Afterward, the drawing position is left at (hn, vn).
>      \D'P h1 v1 ... hn vn'
>           As \D'p', but the polygon is filled.
> 
> > If the polygon is identifiable at the troff level, why can't it be
> > filled there, just by inserting the appropriate troff into the pic
> > diagram?
> 
> You shouldn't need to do even that; GNU pic has supported a "fill"
> attribute for many years.  I believe Research Tenth Edition pic did
> too.

"Shouldn't" might aspirational.  For a box, for a circle, yes, pic has
fill.  For a polygon (which is what Douglas McIlroy mentioned), pic
doesn't have polygons, much less filled polygons.  

        box "hello" fill

produces 

        '\D'P 0.000i -0.500i -0.750i 0.000i 0.000i 0.500i'

but there's no "fill" for 

        line up 1/2 * boxht \
        then right boxwid \
        then down boxht \
        then left boxwid \
        then up 1/2 * boxht

which produces

        \h'1.250i'\v'0.250i'\D'l 0.000i -0.250i'
        .sp -1
        \h'1.250i'\v'0.000i'\D'l 0.750i 0.000i'
        .sp -1
        \h'2.000i'\v'0.000i'\D'l 0.000i 0.500i'
        .sp -1
        \h'2.000i'\v'0.500i'\D'l -0.750i 0.000i'
        .sp -1
        \h'1.250i'\v'0.500i'\D'l 0.000i -0.250i'


I suspect Doug is doctoring the Postscript because it defines a path,
and the input to grops does not, per se.  

>From the user's perspective, I think simplest would be if "line" took a
"fill" attribute subject to the constraint that the line ends where it
begins, something pic can enforce.  In that case, it would draw a solid
polygon instead of a sequence of lines.  

That might be too simple, because the attribute would change the
meaning of "line", including the meaning of "last line .c" and 
placement of the associated text.  I don't know how to compute the
"center" of an arbitrary polygon.  

--jkl