Re: gropdf landscape orientation support (was: [groff] 04/40: [gropdf]: Provide more info in diagnostic message.)

[Blake McBride]

IMO, having multiple ways of specifying landscape is a bad idea and is
bound to lead to never-ending confusion.

Blake


On Fri, Nov 18, 2022 at 9:48 AM Deri <deri@chuzzlewit.myzen.co.uk> wrote:

> On Friday, 18 November 2022 00:30:28 GMT G. Branden Robinson wrote:
> > Hi Deri,
> >
> > At 2022-11-17T21:29:43+0000, Deri wrote:
> > > Hi Branden,
> > >
> > > In papersize.tmac I see this in a comment:-
> > >
> > >   groff -Tps -dpaper=a4l -P-pa4 -P-l -ms foo.ms > foo.ps
> > >
> > > So concept of reversing width height by appending an l has already
> > > been used in groff.
> >
> > Yes, indeed, I'm well aware of this example, having revised much of our
> > documentation around it (it has long appeared in the groff(1) page, for
> > instance).
> >
> > I note emphatically what the above example _doesn't_ say.
> >
> >   groff -Tps -dpaper=a4l -P-pa4l -ms foo.ms > foo.ps
> >                          ^^^^^^^
> >
> > I am concerned about the incongruity between grops and gropdf here.
> > (In the following, "groff" is groff 1.22.4 and "test-groff" is groff
> > Git, my working copy, which is Savannah's HEAD plus your Landscape.diff
> > and some unrelated changes.)
> >
> > $ groff -Tps -P-pa4l /dev/null
> > grops: invalid custom paper size 'a4l' ignored
> > $ groff -Tps -P-pletterl /dev/null
> > grops: invalid custom paper size 'letterl' ignored
> > $ groff -Tpdf -P-pa4l /dev/null
> > $ printf '.tm \\n(.p\n' | groff -Tpdf -P-pa4l
> > 792000
> > $ printf '.tm \\n(.p\n' | groff -Tpdf -P-pletterl
> > 792000
> >
> > $ ./build/test-groff -Tps -P-pa4l /dev/null
> > grops: error: ignoring invalid custom paper format 'a4l'
> > $ ./build/test-groff -Tps -P-pletterl /dev/null
> > ./build/test-groff -Tps -P-pletterl /dev/null
> > grops: error: ignoring invalid custom paper format 'letterl'
> > $ ./build/test-groff -Tpdf -P-pa4l /dev/null
> > $ printf '.tm \\n(.p\n' | ./build/test-groff -Tpdf -P-pa4l
> > 792000
> > $ printf '.tm \\n(.p\n' | ./build/test-groff -Tpdf -P-pletterl
> > 792000
> >
> > Something I'm curious to know is what gropdf in 1.22.4 was doing with
> > "-P-pa4l", since it wasn't rejected and the page length didn't change
> > after Landscape.diff.
>
> I'm surprised you are curious. Altering the dimensions of the medium for
> gropdf can have no effect on groff's read-only register \n[.p]! This
> misunderstanding may be indicative. Invalid paper sizes are silently
> ignored,
> and I agree a warning like grops is needed.
>
> > > There is a fundamental difference between -p a4 -l and -p a4l. The
> > > first is a portrait medium where all strokes to the page are
> > > transformed through 90 degrees.
> >
> > I'm afraid my primitive Neanderthal brain suspects that these might be
> > members of an equivalence class under rotations in SO(3).
>
> Sorry, I don't understand this, my school 8-17 was at a residential school
> for
> disabled kids where no one did academic subjects, so maths was self taught
> later - there are gaps.
>
> > > The second is a landscape medium with
> > > no transformation applied to the strokes. If you consider landscape
> > > printing A5 paper on an A4 printer, you can load the paper in two
> > > orientations, one way round will require stroke rotation, but none the
> > > other way.
> >
> > Being from benighted North America, I must confess to little experience
> > with ISO paper formats.  I admire their properties, and I spent some
> > time in an A4 country, but it was a largely paperless working
> > experience.
>
> You may have missed the point. When using a smaller paper size on a
> printer
> you can put it in "sideways".
>
> > > The example above could be written:-
> > >
> > >   groff -Tpdf -dpaper=a4l -P-pa4l -ms foo.ms > foo.ps
> > >
> > > I hope you have grasped the difference.
> >
> > Alas, no.
>
> This explains a lot. I'm afraid I don't think I have the ability to
> explain it
> better. I just hope others can understand the difference between rotated
> output and non-rotated output.
>
> > > If you examine the contents of the pdf produced you will see
> > > substantial differences even though they may look the same on the
> > > screen.
> >
> > Can you cook up a simple illustrative example?  Maybe use \D escape
> > sequences to draw a couple of intersecting oblique lines so that I can
> > tell the visual orientation of the rendered page; sort of a "THIS SIDE
> > UP" but without text.
>
> I can do better than that. Visually you should see no difference but
> internal
> to the pdf there are many differences, different code path in gropdf.
>
> Using this test file:-
>
> .sp 1i
> \D'p 0 0 -1i -2i 0'
>
> Processing with groff -T pdf -P-pA4 -P-l t.trf produces (within the pdf):-
>
> stream
> q 1 0 0 1 0 0 cm
> 1 J
> 1 j
> 0.4 w
> 0 G
> 0 g
> 84.000 72.000 m
> 84.000 216.000 l
> 12.000 216.000 l
> 12.000 72.000 l
> s
>
> And using groff -T pdf -P-pA4l t.trf produces:-
>
> stream
> q 1 0 0 1 0 0 cm
> 1 J
> 1 j
> 0.4 w
> 0 G
> 0 g
> 72.000 511.000 m
> 216.000 511.000 l
> 216.000 583.000 l
> 72.000 583.000 l
> s
>
> As you can see positions in the second example have not been rotated.
> Origin
> in pdf land is bottom left corner. The first example "works" not only
> because
> each x,y has been transformed, but the pdf instructs the pdf viewer to
> rotate
> the whole page, if I remove that instruction manually (see attached pdf),
> the
> expected result is shown. If you have a portrait printer it can't
> physically
> turn the paper so you have to have some way of telling it to rotate (the
> MediaBox and Orientation), but the marks on the page must be rotated as
> well.
>
> > > You might like to think about whether -dpaper= should trigger an
> > > appropriate \X'papersize' if output is pdf, which would ensure both
> > > groff and gropdf are singing from the same hymn book.
> >
> > I'll probably get more confused before I get less.  I notice you have
> > two distinct rotational variables in gropdf, $rot and $frot, and (now)
> > two different places where rotational transforms are done, complete with
> > slight differences in sign placement so that I have to recall trig
> > identities to satisfy myself whether they're equivalent.[1]
> >
> > 875-            my ($x,$y)=PtoR($theta+$curangle,$hyp);
>
> Perhaps a chat with Professor Corliss :-) and a look at https://
> savannah.gnu.org/bugs/?61908 would help. The code is not mine, it is
> Koichi's,
> but it is handling an arbitrary rotation from pic on top of a page
> rotation
> with -l, so a bit beyond me. $frot is a boolean set by -l flag, $rot is
> the
> number of degrees of rotation (set to 90 if $frot is set), and, before I
> get
> another 3rd degree, $theta is the angle in radians.
>
> > 876-            my ($tx, $ty) = ($xpos - $x, GraphY($ypos) - $y);
> > 877:            if ($frot) {
> > 878-              ($tx, $ty) = ($tx *  sin($theta) + $ty * -cos($theta),
> > 879-                            $tx * -cos($theta) + $ty * -sin($theta));
> >
> > 1499-
> > 1500:    if ($rot)
> > 1501-    {
> > 1502-   ($rect->[0],$rect->[1])=Rotate($rect->[0],$rect->[1]);
> > 1503-   ($rect->[2],$rect->[3])=Rotate($rect->[2],$rect->[3]);
> > 1504-    }
> > --
> > 1509-    my ($tx,$ty)=(@_);
> > 1510:    my $theta=rad($rot);
> > 1511-
> > 1512-    ($tx,$ty)=(d3($tx * cos(-$theta) - $ty * sin(-$theta)),
> > 1513-          d3($tx * sin( $theta) + $ty * cos( $theta)));
> > 1514-    return($tx,$ty);
> >
> > $rot is new and therefore I know that it is used for rotating the
> > MediaBox.  What is $frot for?
>
> Not quite right. The new Rotate subroutine rotates an xy coordinate. The
> code
> you have quoted is part of FixRect which is concerned with adjusting any
> rectangle from groff coordinates to pdf coordinates. In the case of this
> particular fix it is rectangle which defines the clickable hotspot which
> needed rotation in landscape. It is never called for the MediaBox, this
> can
> only be rotated by right angles. In contrast marks on the page can be any
> angle as shown by pics ability to output text by following a line.
> >
> > None of these questions are urgent.
>
> Agreed, it is not a question of speed, it is the effort to put down
> answers in
> an email to questions where you admit you don't understand some of the
> concepts, which makes me grumpy (oh, and old age of course).
>
> Cheers
>
> Deri
>
> > Regards,
> > Branden
> >
> > [1] Maybe all I need to remember is the difference between even and odd
> >     functions.
>
>