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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67866>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
