I opened up a PDF in the default Gnome PDF reader last night, and it was once again a terrible experience. It opened with the zoom set to "fit page width", and the scrolling set to continuous. There's no concept of a persistent user preference, or user preferences that override the document preferences.
Then I got to considering the underlying reasons why I didn't like the default display.
I read a wide range of PDFs from a variety of sources. Some have columns, some don't, and my zoom preference varies based on which it is. If there are columns, I typically make the viewer as tall as possible, set the zoom to "Fit Page", and put up with relatively tiny fonts because then scrolling doesn't keep switching direction to go back up the page when switching columns, then down to the next page (which never aligns with a clean PageDown keystroke).
Without columns, Fit Page Width and continuous scrolling are almost what I want. I really wouldn't mind fitting the content width instead, like OpenOffice's "optimal" zoom, but the page width is typically close enough in spite of losing 10% to the margins. With optimal zoom, I could have the same text size in a smaller window.
But underneath it all, it seems like there's another problem with the interface, carried forward from the days of yore: all scrolling is vertical. On the keyboard, there are no PageLeft or PageRight keys. The mouse wheel offers the vertical axis as a nice wheel, but the horizontal one is reduced to tilting that glorious wheel, which thus becomes as ineffective as the left and right arrow keys for large scrolling.
The vertical bias to scrolling means there's no support for horizontal scrolling. I have a beautiful widescreen display, but I can't use the width except to make a single page extremely wide.
Ultimately, it would be nice to have a PDF renderer that was aware of structure, so that it could destructure the PDF and present it in a screen-friendly way—that is, without columns—on the screen. Presumably, since I can select from a single column at a time, the text is stored linearly inside the PDF (although it also carries glyphs and kerning info, to get that perfectly exact rendition on any interpreter). I'm also guessing that since the text is selectable, there's not a dumb bitmap coming back from libpoppler. And in the event where a PDF turns to mush when trying to linearize it, the faithful representation would be at hand as a fallback, albeit with reduced user happiness.