[XeTeX] [tex-live] -dAutoRotatePages=/None in the distiller_template

[Hironobu Yamashita]

Dear Reinhard,

> Dear Hironobu,
> what do you want to rotate?  An included graphic file or the whole
> document?

> Hironobu, can you tell my why xdvipdfmx has to understand /Rotate?

I meant:
"User-intended pdf figure rotation" is suppressed in xdvipdfmx.
That's a big problem.

> And I'm convinced that /Rotate (with uppercase "R") should be avoided
> because it's not mentioned in the "PostScript language reference",
> third edition, ISBN 0-201-37922-8.  PostScript is an excellent
> programming language, if there were not these annoying Adobe TechNotes.

No, I didn't mean PostScript /rotate but PDF /Rotate. It's natural
that /Rotate (uppercase) does not appear in PostScript Teference,
but it appears in PDF Reference. Many pdf utilities (adobe acrobat,
preview.app, pdftk, etc.) insert /Rotate, and many viewers understand it.

pdfTeX and LuaTeX can understand /Rotate, based on PDF Reference.
Rotating pdf figures is the only correct way of understanding /Rotate.
Current XeTeX and xdvipdfmx simply ignores it.

> Well, at TeX level there is no need to *read* a PDF file, you just
> have to tell what you intend.  Rotating an included graphic file (for
> instance by \includegraphics in LaTeX) means to change the
> transformation matrix first, insert the graphic file, and finally
> restore the matrix.  You have to know the size of the graphic, of
> course.  If you rotate something counterclockwise by 90 degrees, all
> x-coordinates become negative and you have to shift the graphic to the
> right by its height (before rotation) or its width (after rotation).

Of course I know, and pdfTeX and LuaTeX are doing exactly the same
thing as you are saying. They understand /Rotate in PDF correctly.
I wonder why XeTeX does not.

-----
Hironobu