groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

geometric primitives (was: interviews with groff developers)


From: G. Branden Robinson
Subject: geometric primitives (was: interviews with groff developers)
Date: Mon, 7 Aug 2023 10:44:44 -0500

At 2023-08-07T04:55:56-0400, James K. Lowden wrote:
> On Sat, 5 Aug 2023 21:52:26 -0400
> Douglas McIlroy <douglas.mcilroy@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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]