The Page Orientation Problem

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"

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 slide

Teach ghostview/gv to understand what a slide is

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"

Slide, 792 612\n\

Here is my edited version of gv_system.ad.

Teach ghostscript to understand what a slide is

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":

ps2pdf -sPAPERSIZE=slide in.ps out.pdf

Teach LaTeX to understand what a slide is

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

dvips -O0,2.5in -o test.ps test

Then you can use ps2pdf to convert to PDF.

ps2pdf -sPAPERSIZE=slide test.ps test.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:

\DeclareOption{slide}{%
\paperwidth 11in
\paperheight 8.5in
\slidewidth 6.5in
\slideheight 9in
\relax}

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:

\documentclass[portrait,slide]{seminar}

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.