> > *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 <ra...@inputplus.co.uk> 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 > >
