At 2023-08-07T04:55:56-0400, James K. Lowden wrote: > On Sat, 5 Aug 2023 21:52:26 -0400 > Douglas McIlroy <douglas.mcil...@dartmouth.edu> wrote: > > > I can edit the content of figures, which I believe is impossible in > > PDF. One use of this capability is to overcome a > > deficiency in pic: filling polygons. > > I'm surprised you're forced to edit the object code. What is missing > in the pic output that prevents the filling of polygons? > > troff has no concept of "box" or "circle",
It kind of does, of circles.
groff(7):
Drawing commands
Drawing commands direct the output device to render geometrical
objects rather than glyphs. Specific devices may support only a
subset, or may feature additional ones; consult the man page for
the output driver in use. Terminal devices in particular implement
almost none.
[...]
\D'c d'
Draw circle of diameter d with its leftmost point at the
drawing position.
\D'C d'
As \D'C', but the circle is filled.
\D'c' is a Kernighan troff, a.k.a. CSTR #54 (1992), feature.
Filled objects are a later development, not standardized.
But groff does support "boxes", if you will.
\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.
pic(1):
Boxes (including boxes with rounded corners or slanted sides),
circles and ellipses can be filled by giving them an attribute of
fill[ed]. This takes an optional argument of an expression with a
value between 0 and 1; 0 will fill it with white, 1 with black,
values in between with a proportionally gray shade. A value
greater than 1 can also be used: this means fill with the shade of
gray that is currently being used for text and lines. Normally
this will be black, but output devices may provide a mechanism for
changing this. Without an argument, then the value of the variable
fillval will be used. Initially, this has a value of 0.5. The
invisible attribute does not affect the filling of objects. Any
text associated with a filled object will be added after the object
has been filled, so that the text will not be obscured by the
filling.
Additional modifiers are available to draw colored objects:
outline[d] sets the color of the outline, shaded the fill color,
and colo[u]r[ed] sets both. All expect a subsequent string
argument specifying the color.
circle shaded "green" outline "black"
Color is not yet supported in TeX mode. Device macro files like
ps.tmac declare color names; you can define additional ones with
the defcolor request (see groff(7)).
On top of the usual reason using pic(1) features is preferable here,
there is the problem of implementations not being consistent about
behavior details like:
1. Does a drawing command that doesn't draw anything move the drawing
position?
2. It is up to the formatter to close the polygon in the \D'p' command,
or is this actually a "polyline" command that we don't need because
we already have \D'l'?
3. Which drawing commands should break the rule that the drawing
position is left at the rightmost point of the object?
GNU troff has some bugs here. DWB 3.3 and Heirloom Doctools troff have
more. I haven't looked at plan9port or neatroff in these respects yet.
https://savannah.gnu.org/bugs/index.php?64285
https://savannah.gnu.org/bugs/index.php?64308
Regards,
Branden
signature.asc
Description: PGP signature
