The Page Orientation Problemby Allen B. Downey
I think the concept of Page Orientation is fundamentally broken in a way that is making it confusing to produce, display and print electronic documents. For example, if you use a WYSIWYG text editor to produce slides, you typically choose the paper size "letter" and the orientation "landscape." What appears on the screen is a page 11 inches wide and 8.5 inches tall.
If you generate a Postscript version of this document and send it to a printer, it ought to print correctly, meaning that it appears on a page that is 8.5 inches wide and 11 inches tall, but the text is rotated 90 degrees to the left. All you have to do is rotate the paper and all is well.
But now let's say you view the document using ghostview or another Postscript viewer. By default the pages appear sideways. Again, though, you can use a menu to rotate the page so it is legible on the screen.
Finally, what happens if you convert the document to PDF? Again, the pages appear sideways, but now you have a problem. Acroread does not provide the ability to rotate a page on the screen. If you were planning to use it to project your slides, you are out of luck.
When I ran into this problem, I searched the web for people with the same problem, and I found lots. But I did not find anyone with the answer. In some cases, with some applications, it is possible to work around the problem, but I don't find those solutions satisfying.
Stop saying "landscape"I think there is a fundamental conceptual problem here that is confusing both application writers and users. The problem is that the notion of "Page Orientation" is confounding two different issues: the aspect ratio of the page and the rotation of the text and images relative to the page.
Let's start at the top. Postscript and PDF are page description languages, which means that they contain code that describes the contents of a printed page, but they are device independent, which means that they do not depend on the properties of a printer (like resolution) or piece of paper (like size); in fact, they are not even specific to a medium. Postscript documents can be printed, displayed on a monitor, projected, etc. I will call device-independent descriptions like this "electronic documents."
At least in theory, the size of an electronic document has nothing to do with the size of a piece of paper. It might have dimensions that match the size of a monitor, or it might be specified in abstract coordinates that have no relation to reality. Only when the document is rendered---converted to a device-specific form---do we have to specify how it should be mapped to a particular medium.
But in practice, many electronic documents contain information about how the document should be rendered: page size, orientation, etc. That's where the problem starts, because now it is hard to create a document that can be rendered on screen and also printed.
Here's what I think should be done to solve this problem:
First, we should strike the words "landscape" and "portrait" from the vocabulary. They describe the aspect ratio of a page; landscape is wider than tall and portrait is taller than wide. But these terms are useless for page description.
Second, when we choose a page size for an electronic document, we should forget about the sizes that paper happens to come in and printers happen to print. For example, a slide is not an 8.5 by 11 piece of paper sideways. It is a page that is 11 inches wide and 8.5 inches high. That's how it looks when we write it and that's how it should look on the screen. It is "landscape" in the sense that it is wider than it is tall, but that has nothing to do with rotation. It should appear on the screen with text running top-to-bottom, left-to-right.
Third, page description languages should provide pragmas so that documents can contain hints about how to render a document on paper. For example, slides would contain the helpful suggestion that they can be printed on an 8.5 by 11 piece of paper sideways. Similar hints might suggest scaling or shifting the electronic page before rendering it.
Postscript already has a pragma mechanism, called document structuring convention (DSC) comments. Unfortunately, it also provides operators, like setpagedevice, that provide similar functions. As far as I know, the Postscript language specification does not clarify the proper use of these alternative mechanisms, and applications that produce and translate Postscript are not consistent in their use. As a result, many electronic documents are not rendered consistently in different media.
Finally, we should develop filters that take electronic documents and prepare them for rendering, either by interpreting and obeying pragmas or by overriding the pragmas based on user input. In other words, device-specific decisions should be postponed until the document is rendered.
Ok, that's the end of the rant. Now here are some actual suggestions.
The concept of a slideHere is my suggestion about how to solve this problem (at least the specific problem of generating slides). The general approach is to define a new kind of paper, called "slide", that is 11 inches wide and 8.5 inches high. When we generate slides, we select this paper size and lay out the text in the usual orientation, that is, not sideways. As long as all the applications that handle this document know what a slide is, everyone is happy. The following sections explain how to teach applications what a slide is.
Teach ghostview/gv to understand what a slide isThese comments are based on gv 3.5.8, which seems to be the successor of ghostview 1.5
We need to change the "media resources" for gv, which is a little tricky because gv reads a number of resource files on startup, and it is not easy to figure out which one is read LAST, and therefore takes priority.
If you just want to fix the problem for yourself (single user), just change ~/.gv
If you want to fix it for everyone on the system, you have to fix all the existing .gv in home directories, and then the parent file, which is either gv_system.ad or gv_user.ad, possibly located in /usr/X11R6/lib/X11/gv (consult the man page). Also, just for kicks, you might want to fix GV, possibly located in /usr/X11R6/lib/X11/app-defaults/GV. Personally I think it is a bad idea to have so many configuration files and such a poor explanation of how they interact, but maybe there is a good reason for it that I don't understand.
Anyway, you just have to add one line to the section named "GV.medias"
Here is my edited version of gv_system.ad.
Teach ghostscript to understand what a slide isIf you are using ps2pdf to converts slides to PDF, you can make a simple change to the ghostscript configuration.
The configuration file is called gs_statd.ps. You can use slocate to find it on your system. On mine it is in /usr/share/ghostscript/5.50. Edit it to create a new kind of paper, called slide, that is 11 inches wide and 8.5 inches high.
Here is my edited version of the file. If you search for the word "slide" (or diff this with your version) you will find the two lines I changed.
When you run ghostscript (or ps2pdf), use the PAPERSIZE option to specify the size named "slide":
Teach LaTeX to understand what a slide isIf you are using the slides class to write slides in LaTeX, you can go ahead and use the "landscape" option, which in this context means that the page is wider than it is high, but not rotated.
If you use dvips to process the output, you have to shift the page down by 2.5 inches. I have no idea why, but here is the command
Then you can use ps2pdf to convert to PDF.
If you are using the seminar class to make slides, life is harder. First you have to teach seminar.sty what a slide is. On my machine, seminar.sty is in /usr/share/texmf/tex/latex/seminar/
Add the following lines to explain what a slide is:
Here is my edited version of seminar.sty. I have changed the name to seminar_slide.sty to indicate that this is not the original version, in accordance with the distribution license. Now in your LaTeX source you should specify the slide option AND the portrait option, as in:
In portrait mode you have to use the slide* environment rather than slide.
Again, you'll have to give dvips the mysterious 2.5 inch offset, but other than that, everthing should work fine.