One of the reasons that Apple chose to use a 4:3 ratio screen on the iPad, rather than a 16:9 widescreen, is that they saw it as more of an “e-reader” device than as something for watching movies. The 4:3 ratio is very close to the ratio of magazines and Apple assumed magazine apps would be popular iPad content.

The “standard” magazine size is approximately the same (trimmed) as US Letter sized paper at 8.5″x11″ or alternatively slightly less at 8.375″x10.875″ – the size depending largely on how it is ultimately going to be printed.

In the world of print the smallest unit is the “point.” In the world of computer layout the smallest unit is the pixel (actually its the ONLY unit). Early computer displays were very low resolution, but the screen of the first Apple Macintosh in 1984 had 72 pixels per inch. In the printing industry there are 72 points per inch. It made for a perfect 1:1 translation of what was on screen to what was on the printed page (“What You See Is What You Get”). It worked out nicely for the Graphic Design, Publishing, and Printing industries – who all were early adopters of the Macintosh and accustomed to thinking in terms of 72 points per inch. It also allowed Macs to scale the fonts perfectly into pixels. 10 points = 10 pixels = 10 ems. It was a different story on Windows systems, which chose 96 dpi to “blow up” things to 133% as a way to compensate for the fact that you view a screen at a greater distance than a printed page (read about that in detail at th MSDN blog: http://blogs.msdn.com/b/fontblog/archive/2005/11/08/490490.aspx)

The first Mac was all about translating (as exactly as possible) computer layouts to the printed page. In trying to adapt a magazine layout to the iPad things are going in the opposite direction. The iPad’s actual pixel density is 132 ppi (there are 132 pixels for every actual inch of the screen). But computer displays don’t really pay attention to the dpi/ppi setting of images. It’s only used for text rendering, and even then it would only be directly transferable if the “logical inch” and “actual inch” were the same.

Which means we don’t care about the pixel density of the screen. Mobile devices today use “device independent pixels” (dip) for UI rendering purposes, and these are scaled to the device’s actual pixel density. It’s how the iPhone 4 can have a 326 ppi screen yet still display things at the same “size” as the 163 ppi iPhone 3 (it simply scales each dip x 2). All of Apple’s devices use the 72 dpi standard for text rendering, regardless of the actual pixel density of the screen (note, however, that Apple recommends developers provide double resolution images for the iPhone 4 “retina” display, so when they are scaled up two times they won’t look blurry).

Back to our printed magazine, at 72 dpi it would be just 612 pixels x 792 pixels. That would certainly fit on the iPad screen, with plenty of room to spare! That extra room might not be wanted, though. If you scale the width to fill the iPad’s screen in portrait mode (which you’d likely want t do) it’s a simple scale factor of 125% (rendering pages 768 x 990) which – at least in “App View” mode – is enough to still provide 14 extra pixels (enough for a touchable bar that opens up controls) or if delivered as an actual app that can hide the status bar room for 34 pixel high buttons along either the top or bottom.

While “App View” for web sites bookmarked to the home screen provide a maximum of 1004 pixels in height for the layout and controls, there is considerably less space available in “Web View” mode inside the Mobile Safari browser at only 946 pixels. Letting it scroll is one option, but not a great one. Another is to use the available height to scale the layout – which would be 114% if you want to leave enough room for a toolbar (44 pixels high) or 119% for no toolbars (actually falls short a bit).
In landscape orientation a two-page spread dictates the page width be 512 pixels, or the standard size x .837. That makes the height 663 pixels, which will fit in both “Web View” (690 px) and “App View” (748px).

However, this won’t work as well for an Android tablet. For example, an tablet running Android 3.0 “Honeycomb” at the default screen density of 160 dpi and browser set to the default zoom level of “medium” will have 1280×648 available – enough for the spread width of 1024, but not enough for the page height of 663. The only real solution in this case is to reduce the height of the pages so they fit, which necessitates building the pages with a flexible “middle” section that can assume the reduced height. A device (phone or tablet) running a lower version of Android (up to 2.3.3) with the same screen density and browser zoom setting will have only 800×401 available. Not really enough for a two-page spread view, so an alternative landscape view needs to be created for devices that still have too narrow a viewport even in landscape mode (which would also include any iPhone or iPod Touch).

For desktop browsers, which are most likely to be in “landscape” orientation the iPad’s 1024 setting will also work. However, if the user has a much larger monitor that page view starts to look a bit small. So in a browser wider than 1280 the pages can be increased to 640 pixels wide (it’s an oddball percentage larger than the base dimensions of the magazine, but is nicely 125% the width of the iPad view). What the height might be is anybody’s guess. Consider the following browsers, displaying default toolbars, etc., on a Mac with the dock hidden:

Safari5:1280 x 966
Chrome 10: 1280 x 960
Firefox 3: 1280 x 967
Firefox 4: 1280 x 966
Opera:1280 x 951

That means it’s possible a user might have enough vertical space to display a 828 px high page, but you can’t be certain. They may not have the browser maximized vertically, they may have extra toolbars. You don’t know. As with the Honeycomb Android tablet scenario, the safest thing would be to have a variable height.

With HD monitors becoming common, resolutions over 1600 pixels can be expected. That would allow for two 800 pixel wide pages, which is conveniently another 125% larger than the widths for 1280 screens (so if this scaling was being handled programmatically, instead of via stylesheets, it would be a simple conversion from one landscape size to the next). However, that would make the height 1035 pixels when scaled from the original magazine format! While a 4:3 ratio monitor at 1600 pixels wide would theoretically have enough room, a widescreen monitor has a device height of only 900 pixels. Yet again, the height needs to be made variable.