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

[Deri]

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.

L-NoPageRotate.pdf
Description: Adobe PDF document