On Mon, 7 Aug 2023 10:44:44 -0500
"G. Branden Robinson" <g.branden.robin...@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
