Re: [Groff] Problems with arcs and angles

[John Gardner]

>
> *The documentation is correct. The code is wrong. Later code copied
> earlier code.*


Ugh, that's even more confusing. Looks like gropdf's comments could do with
a clean-up: these lines had me confused as well:

# do it in 4 pieces

my $totang=($endang-$startang)/4;


> # Now 1 piece
> my $x0=cos($totang/2);
> my $y0=sin($totang/2);
> …



*In the groff source, adjust_arc_center() seems the culprit that many of
> the output devices call to mess with arc's calculations.*


Well... right and wrong way aside, I'm simply glad to have achieved parity
with grops/gropdf. Here's a rendering <http://i.imgur.com/M4vwNaN.png> of
Eric Raymond's graph used on page 28 of "*Making Pictures with GNU PIC"*.

Needless to say, it'll be interesting to browse system documentation in
graphical form, with manpage references appropriately linked...


On 9 May 2017 at 22:16, Ralph Corderoy <address@hidden> wrote:

> Hi John,
>
> > Looks like there's a mistake in groff_out(5). It describes its
> > arc-drawing command as:
>
>     Da h1 v1 h2 v2⟨line-break⟩
>         Draw arc from current position to (h1, v1)+(h2, v2) with center
>         at (h1, v1); then move the current position to the final point
>         of the arc.
>
> CSTR 54 says
>
>     Da dh1 dv1 dh2 dv2
>         draw arc from current position to dh1 + dh2, dv1 + dv2, center
>         at dh1, dv1 from current position
>
> I think they're equivalent.
>
> > However, gropdf.pl tells a different story. To quote line #2791:
> > <http://git.savannah.gnu.org/cgit/groff.git/tree/src/
> devices/gropdf/gropdf.pl?id=453a8aa7c8f8dd0c78160466301f81be8c40df2e#n2791
> >
> >
> >     Documentation is wrong. Groff does not use Dh1,Dv1 as centre of the
> >     circle!
>
> The documentation is correct.  The code is wrong.  Later code copied
> earlier code.
>
> > I noticed something odd when drawing an arc which wasn't an
> > evenly-sized quarter-circle. For instance, the following Pic code:
> >
> >     .PS
> >     move down
> >     A: box
> >     arc at A.n
> >     line right
> >     .PE
>
> I think pic produces correct troff for this, but then grops and many
> others interpret it wrongly.  You initial attempt is correct, even
> though it produces the "wrong" diagram.  "at" for an arc sets the centre
> point;  that's A.n.  It will be anti-clockwise.  We finish the box at
> A.s.  The start of the arc is after the implicit move downwards at that
> start.
>
> Here's some additions to your test.
>
>     .PS
>     move down
>     A: box
>     arc at A.n
>     arc; arc; arc; arc
>     line right
>     line from A.n to A.n - 0, A.ht * 2
>     line from A.n to A.n + arcrad * 2, (-A.ht - arcrad) * 2
>     .PE
>
> The four arcs are to draw a circle, returning to the start point, so you
> can see grops's arc's radius isn't the default.  The two extra lines
> show the correct CSTR 54 interpretation of where the arc should start
> and end, as indeed it does when viewed with `groff -pX foo.pic'.
>
> To see groff's interpretation,
>
>     pic foo.pic | perl -pe 's/\\D/$n++; "\\Z%$n%$&"/ge' |
>     groff | ps2pdf - foo.pdf
>
> I'd guess gxditview gets it right because it has a pre-groff heritage
> and so coded to Kernighan's DIT output, as you originally did.
>
> In the groff source, adjust_arc_center() seems the culprit that many of
> the output devices call to mess with arc's calculations.
>
> --
> Cheers, Ralph.
> https://plus.google.com/+RalphCorderoy
>
>