UPDATE: With the v23 release, it’s now possible to create a single 1024×768 PDF folio that looks great and performs well on both the older 1024×768 models and the new 2048×1536 model. There are three main improvements: (1) background images are now output at 108 ppi instead of 72, (2) you can use a vector format for slideshows and scrollable frames to avoid text pixelation, and (3) you can include both SD and HD assets in the folio for certain overlays. I made a few edits to this blog entry, but you can learn more details by reading Creating multi-rendition articles for iOS devices.
The new iPad (Generation 3) is out. The new model has twice the resolution of the previous model. What do 1024×768 folios look like on the new device? And what’s the best approach to creating folios to account for the different devices? And when will the new device be fully supported?
When the new iPad finally arrived on my doorstep, I dropped everything to start testing it. The scaled 1024×768 JPG/PNG content looks reasonably good on the 2048×1536 device. Images look great, and nearly all overlays perform well (and don’t look pixelated when scaled up). Text is noticeably fuzzy in many areas, especially body text and light text against a color background. The performance is excellent, despite the fact that the viewer has to do some extra scaling. The new processor more than compensates for additional scaling calculations.
If you’re in a hurry, here’s the executive summary.
- Use PDF image format instead of JPG/PNG. PDF results in smaller article size and maintains vectors. To avoid rasterizing text in slideshows and scrollable frames, you can choose Vector in the Overlays panel if the viewer and folio are v23 or later.
- For single-issue viewers, you cannot create renditions. We recommend creating a single 1024×768 v23 or later folio with PDF image format for articles. This approach works for all iPad devices. For details, see Creating multi-rendition articles for iOS devices.
- For multi-issue viewers, you have a number of choices. The easiest rendition approach is to create 1024×768 source documents and use these as the basis for both the 1024×768 folio and the 2048×1536 folio. You might want to show/hide layers for certain overlays such as videos and pan & zoom images.
To help you make design decisions, let’s go over a few key points.
How Folios Are Rendered
First, it’s important to understand how folios are rendered. Any non-interactive content that appears on your page is resampled when the article is created. If your folio is 1024×768, all the non-interactive content on a page is compressed to a 1024×768 72-ppi image using the article’s image format setting: PNG, JPG, or PDF. (In v23, the PDF image format uses 108-ppi.)
Rule of Thumb 1: Use PDF image format if possible. PDF yields smaller folios.
If your folio is 2048×1536, a 2048×1536 72-ppi background image* is rendered for each page. Non-interactive page items are scaled to conform to the folio size, regardless of the source documents’ size. For example, you could create 512×384 source documents with a 2048×1536 folio, and the content would get scaled up to the folio size. That offers a great opportunity to create two renditions from the same set of source files. But more on that later.
* I’m oversimplifying this. What I said is true of JPG/PNG folios, but it’s more complicated for PDF folios. A JPG or PNG-format article is rasterized at 72 ppi and is the dimension of the folio. However, PDF-format articles for 1024 and 2048 folios have the same dimension, but have a different resolution value for the SD and HD folios. For pre-v23 folios, PDF articles had 72/144 resolution values. For v23 and later, PDF articles have 108/216 resolution values.
Overlays are handled differently than non-interactive items. Some overlay source files are resampled while others aren’t. When the article is created, certain overlay source files are uploaded to the server without any compression. Let’s call these “pass-through overlays.”
The following overlays are not resampled. The source files are uploaded directly to the server.
- Videos (and audio clips)
- Image sequences
- Audio controller skins
- Pan & Zoom images
The following overlays are resampled in the same way that background content is resampled.
- Scrollable Frames
Rule of Thumb 2: If possible, use different assets in each rendition for pass-through overlays. Doing so reduces folio size for older iPads and optimizes appearance for the iPad 3.
Where to Scale Content
One other important issue to discuss: If a folio has a different size than the device, the viewer needs to scale the content either up or down. Whenever the viewer scales content, there is a memory hit that can affect performance. If content is scaled up, images and especially text can appear blurry.
Rule of Thumb 3: Whenever possible, let the Folio Builder tools do the scaling, not the viewer.
First Approach – Two Renditions, Two Source Files
The ability to create renditions to account for different Android devices has been around for awhile. Beginning with the v19 tools, renditions are supported on iOS devices. This means you can create two different folios — one 1024×768 and one 2048×1536. If you set up the metadata properly, only the 1024×768 folio is available on the iPad 1&2, and only the 2048×1536 folio is available on the iPad3.
Rule of Thumb 4: Use renditions for multi-folio apps to support all iPad devices and minimize folio size.
Renditions work only for multi-issue viewer apps. I’ll discuss single-issue apps later.
To get the most out of renditions, create two different folios — 1024×768 and 2048×1536 — and two sets of source files. For the interactive overlays that aren’t compressed, such as videos and image sequences, consider creating separate source files for each rendition. (By the way, even if I use a separate set of source files for the 2048×1536 folio, I still prefer working with 1024×768 source files.)
With full renditions, content is optimized for both iPad sizes.
Even though this image shows two different sets of source files, you can use a clever trick to use the same set of 1024×768 source files for both renditions. When you create the source files for the iPad 3, they don’t need to be 2048×1536 articles. They can be any size as long as they have a 4:3 aspect ratio (not including smooth scrolling articles).
When you create the 2048×1536 folio, smaller articles are scaled up. Your text will scale up just fine. For non-interactive images, use a reasonably high resolution. And here’s where the trick comes in. Use the Layers panel to handle pass-through overlays. When you create the articles in the folio, hide or show the layers as needed.
Content on hidden layers is not included in the article when it’s created.
For example, you can place a 400×300 72-ppi image sequence on the layer for low-resolution overlays. Then place an 800×600 72-ppi image sequence on the layer for high-resolution overlays. Scale the high-resolution image sequence by 50% to make the effective ppi 144.
- Content is optimized for each device. iPad1&2 folios are no larger than necessary.
- The viewer isn’t required to scale any content.
- iPad3 folio content is clear and crisp.
- Extra production work is required.
- Renditions are not available for single-issue apps.
Second Approach – Two Renditions, One Set of Source Files
You might not have time to create two sets of source documents or redesign source documents for each rendition. The next best approach is to use a single set of source files to create two different folio renditions. The advantage over just creating a single folio is that you’re making the Folio Builder panel do the scaling rather than the viewer, resulting in better performance.
You can create folios and source files in either 1024×768 or 2048×1536 format, although using the smaller source files is perfectly fine. Make sure that you use the “Import Multiple Files” technique when creating the new rendition. Using the sidecar.xml file adds all the appropriate metadata.
With renditions based on one set of source files, your content is scaled before it gets to the viewer.
- Minimal production work is required.
- Viewer does not have to scale folio content, resulting in improved performance and appearance.
- Non-interactive content can be optimized for each device if you use high-resolution images.
- When scaling up 1024×768 articles, interactive content might appear fuzzy.
- When scaling down 2048×1536 articles, folio size increases due to larger overlay assets.
Non-Rendition Approach (1024×768 only)
With this approach, you continue to create 1024×768 folios without bothering with renditions or any extra effort. If you use the PDF image format and avoid using text in overlays, this approach can work very well.
The viewer scales up 1024×768 content for the iPad 3, likely resulting in some pixelation.
- Less design and production work.
- In a multi-issue app, content appears on all iPad devices.
- The viewer scales up content for iPad 3, which can make text and some images appear pixelated, especially in articles with JPG/PNG image format. As I mentioned, the v23 multi-rendition article feature improves this issue. See Creating multi-rendition articles for iOS devices.
Non-Rendition Approach (2048×1536)
With this approach, you create only 2048×1536 folios and articles to target only the iPad 3 model. We don’t recommend this approach.
2048×1536 folios do not appear in the viewer library of iPad 1 & 2 devices.
- Minimal design and production work.
- Content looks crisp and clear on iPad 3.
- You still need to convert your workflow to 2048×1536 folio size.
- In a multi-issue app, 2048×1536 folios are not available in library for iPad 1 and 2 viewers.
Creating Single-Issue Apps
We recommend that you create a 1024×768 folio using PDF image format. With this approach the 1024×768 content scales up nicely for the iPad 3, especially if you take advantage of a few v23 features mentioned in Creating multi-rendition articles for iOS devices.
Other iPad 3 Considerations
- Let’s suppose you publish a 1024×768 folio and then a week later you publish a 2048×1536 rendition of that folio. If your iPad 3 customers open the library before the larger rendition is available, only the smaller rendition remains available — they don’t get an update notice, and only the smaller rendition remains available. The only way for them to get the larger rendition is to remove and reinstall the viewer app. (This issue is scheduled to be fixed in an upcoming release.)
- If you have a Newsstand app, do not trigger a push notification until all renditions have been published as public and are available.
- When using DPS App Builder (previously called Viewer Builder) to create or update your viewer, create two sets of icons, splash screens and other images. For example, specify 1024×768 and 768×1024 images for the iPad1, and 2048×1536 and 1536×2048 images for the iPad3. The newest version of the Viewer Builder provides these additional options.
- I haven’t tested cover images yet, but I think it’s fine to continue providing only 1024×768 and 768×1024 images. The safest approach is to double the size of these images, which are scaled down as needed.
- If you want to specify thumbnail images for imported articles, include a 140×140 image (instead of 70×70 images) for iPad 3 renditions.
- To create renditions, make sure that you use the exact same Folio Name in the two folios. If it’s a retail app, use the same Product ID and Publication Date.
Help article about designing for multiple documents
Help article about creating renditions
Help article about Creating multi-rendition articles for iOS devices
Colin Fleming’s article about targeting the new iPad 3