>> Alternatively {"corners" of a polygon} could lie on the edges of supporting
>> compass half-spaces.
> I'll have to think harder about that remark.
I realized it was cryptic when I wrote it, but did nothing about it.
What I meant is
1. Draw a polygon
2. Imagine sweeping an infinite line across the plane, keeping the
line perpendicular to a given compass direction.
3. Stop the sweep exactly when the line touches but does not penetrate
the polygon.
4. If there is exactly one point of contact, that is the corner for
the given compass direction.
5. Otherwise, identify maximum and minimum points of contact, in the
sense of a metric measured along the sweep line. The "corner" is
halfway between these two points.
Notes.
4 is a special case of 5 .
It's possible for a "corner" to be outside, not on, the polygon.
.e and .w won't necessarily have the same y coordinate.
Applied to ellipses, this definition puts "corners" at points of slope
-1,0,1,infinity.
This definition could be applied to splines just like ellipses with
two extra candidates for points of contact: .start and .end.
Alternatively it could be applied to the control points. And finally
it could be applied to multisegment lines.
In the course of writing this, I turned up another anomaly: xslanted
and yslanted do not affect the "corner" values of a box. This is
perhaps consistent with the convention that a box moves the current
point in a cardinal direction, but I cannot believe anyone would want,
say, to draw an arrow to the pre-slanting corner of a slanted box.
xslanted and yslanted probably should be deprecated in favor of
polygons, so I think this anomaly should not hold up 1.24. However, it
does shed an unflattering light on my support-line proposal. Where
would the "corners" of a box rotated slightly counterclockwise be? .n
would coincide with .ne, .e with .se, and so on. This seems
unintuitive; I'll have to ponder it.
Doug
On Tue, Dec 30, 2025 at 9:22 PM G. Branden Robinson
<[email protected]> wrote:
>
> Follow-up Comment #3, bug #67866 (group groff):
>
> [comment #2 comment #2:]
> > I only had only splines in mind for the bounding box idea, I would
> > place the "compass points" on the bounding box of the control points,
> > pic says .c lies halfway between .start and .end.
>
> That sounds like a good place to start. If I'm the one who implements it,
> completing that would offer me an opportunity to establish a foundation on
> which to construct my further projects seeking generality and consistency.
>
> > Compass points for text objects are already defined as being on the
> > bounding box, except the "bounding box" is defined by variables
> > textwid and textht, not(!) by the text content.
>
> Hmm, yes. I believe I'm familiar with this problem, which arises from _pic_
> not having access to glyph metrics at the time it runs, because it's a
> preprocessor.
>
> An ambitious person could extend GNU _pic_ to use our internal static
> _libdriver_ library to get at that information, but we'd probably also need a
> way to announce to _pic_ what the typeface, type size, and (stretch goal)
> "height" and "slant" are, since we certainly don't want _pic_ attempting to
> interpret _troff_ input for itself. (Additional "arguments" after the "PS"
> token, maybe?)
>
> Doing that would demand adding a `-T` command-line option taking the output
> device type to _pic_ itself, so that the preprocessor would know which
> device's font metrics to look up.
>
> > You suggest that for some figures, in particular circles, the compass
> > points would be on the intersection of the figure and rays from
> > somewhere (.c?) to the corners and mid-edges of the bounding box. For
> > ellipses that would be the same as what I called flattening or
> > squashing.
>
> I think I see. I should confess that I don't know how reference points would
> interact with my hypothetical 3-by-3 matrix operator for generalized
> transforms of _pic_ objects (bug #67229).
>
> > If version 24 has polygons, the bounding box idea might be pertinent there.
>
> Yes, polygons are implemented and expected in the release, thanks to Duncan
> Losin; bug #66458.
>
> > Alternatively they could lie on the edges of supporting compass half-spaces.
>
> I'll have to think harder about that remark.
>
> > The existence of corners is visible in the syntax, but the meaning is not.
>
> Kernighan, _j'accuse_!
>
> I kid. We'll figure something out.
>
>
>
> _______________________________________________________
>
> To reply to this notification, you have two options:
> * In the Web UI at <https://savannah.gnu.org/bugs/?67866>.
> * By email to 347287-bugs-savannah <[email protected]>, ONLY IF you
> preserve both
> the 'display name' and the 'address specification' in the To: header
> AND you sign your email with a GPG key registered in your Savannah account
> AND you include the following line in the reply:
>
> {savane: user = 347287; tracker = bugs; item = 67866}
>
> _______________________________________________
> Message sent via Savannah
> https://savannah.gnu.org/
>
