# Should I prefer {pdflscape} over [pdftex]{lscape}?

I came across a problem with pdflscape and TikZ' external library where externalized tikzpictures in a landscape environment were rotated incorrectly ( Using tikzexternalize with pdflscape results in rotated image). Apparently, this is a known bug (added to the pgfplots "to-do" list in 2009).

In my case, it turns out that everything works fine if I use \usepackage[pdftex]{lscape} instead of \usepackage{pdflscape}: The landscape page is correctly rotated and displayed in the PDF viewer, and the externalized image is oriented correctly.

Is there a reason why I should not use [pdftex]{lscape} instead of the {pdflscape} package? It seems that both do the same thing (make sure that landscape pages are displayed in landscape mode in the viewer). However, on the lscape CTAN page it says:

Note that the package makes no special provision for PDF output, where in principle a single page can be shown at full landscape width; such an effect may be achieved using the pdflscape package instead.

Why does the lscape package recommend using pdflscape instead of its own pdftex switch?

• pdflscape rotates the page using magic that makes the page appear "right" (fsvo right) in a viewer, only. lscape doesn't do that. – wasteofspace Jun 27 '12 at 9:24
• @wasteofspace: If I understand correctly, with the [pdftex] option, lscape also adds the necessary PDF literals to cause the page to be displayed correctly. From the lscape documentation: "[Scott Pakin's] addition makes lscape rotate the PDF ”paper” – not just the text on the page – when given the pdftex option." – Jake Jun 27 '12 at 9:25

Answering the various points "why does lscape package recommend a different package" well it doesn't really. The ctan catalog package descriptions are not (in general) by the package authors but a third party review of the package.

There are three places that "rotation" can occur when considering a page in a pdf file. lscape only considers one of them [* see note at end about [pdftex] option] and pdflscape considers two.

To make a page landscape you need to:

• first switch round \textheight and \textwidth (and a few other associated lengths). That much you can do in pure TeX.

• Then you need to rotate the text box on to the page (since lscape doesn't move the page numbers) This is done by using \rotatebox from the graphics package and so needs driver dependent code specified by a package option or defaulted from graphics.cfg.

• For printing, that's all you need, but for viewing you might want to rotate the "entire page" the other way so that on-screen the main text is vertical and the effect is that the page outline is rotated to landscape. pdflscape inserts additional code to rotate the view in the viewer.

• But ... some pdf viewers use heuristics to determine the orientation of the "main" text on a page and rotate the page view even when not explicitly specified.

As far as I know you can't reliably rotate the page view in ways that work for all configurations of all viewers. If as in the original lscape you ignore the issue the page will look fine if using a viewer that auto-rotates and the page has sufficient text that it can tell which way is up (It's harder to tell which is up for images). If you force the view to rotate as in pdflscape then (I think) if the viewer auto-rotates the it gets rotated twice so ends up the wrong way up. It would be nice to be able to say "this way up" but I don't think that's possible (and it isn't what either package does) you can only say "rotate the view" from a default that might change depending on the viewer.

At least I think that's the situation, I never actually used pdflscape but I had a quick look at its code while writing this:-)

Ah. As noted above I checked the code for the "other" package but didn't check the code of "my" package. ...

So apparently back in 1999 I accepted a 3rd party diff so that lscape also affects the pdf page view attributes if used with [pdftex] . Sorry the version in my head was the original:

% \changes{v3.01}{1999/06/22}{Added better pdfTeX support
%    by Scott Pakin, from graphics/3063}
%
%
%    \begin{macrocode}
%<*package>
%    \end{macrocode}
%  Here is what Scott Pakin wrote about the pdftex option:
% \begin{quote}
%    I've made a minor improvement to lscape.dtx that I'd like to share
% with the world.  My addition makes lscape rotate the PDF "paper" --
% not just the text on the page -- when given the "pdftex" option.
% (Naturally, this works only with pdfLaTeX.)  The result is that the
% text is viewable online without the reader having to rotate his/her
% head 90 degrees.  The document still prints normally.
% \end{quote}


  \ifGin@pdftex
\pdfpageattr{/Rotate 90}
\fi


So I think that there effectively isn't any difference for pdftex but pdflscape adds equivalent code for many other driver back ends such as dvips or dvipdfm. Sorry about the confusion.

This also explains why you need to use [pdftex] explicitly lscape handles that itself to add the code shown above. It would probably be better if instead it just let graphics handle the options and then make an internal check to see which driver backend graphics ended up using. That way it would also work if the graphics driver were defaulted from graphics.cfg (as is usually the case with graphics package options).

• Okay, thanks for that. I get the difference between lscape and pdflscape, but I'm still unsure about the difference between [pdftex]{lscape} and pdflscape. It seems to me that they both do the same: Explicitly setting the page rotation in the PDF viewer (which may or may not lead to problems with auto-rotation, but I haven't encountered those with either package). – Jake Jun 27 '12 at 11:54
• Answer updated. – David Carlisle Jun 27 '12 at 12:26
• Thank you, David! All makes sense now. And sorry for flogging this so long! – Jake Jun 27 '12 at 12:44
• @david: of course the catalogue descriptions aren't written by the authors. the ideal is that the catalogue description comes from the summary of the package when it's uploaded, but most uploads contain nothing useful there, or in the readme file (if there is one). and apart from that, there are all the packages that exist with no docs, not even comments in the code. maintaining the catalogue should be a full-time job, given the amount of time required simply reading code. no surprise that the catalogue author makes mistakes. – wasteofspace Jun 27 '12 at 13:22
• (of course, people, who don't like what the catalogue says, should submit an error report to ctan@dante.de -- there are often as many as one or two a year, there. probably people don't read the catalogue much.) – wasteofspace Jun 27 '12 at 13:25