This type of HTML layer is only supported for the iOS app. For other apps, a SWF equivalent should be used. YUDU can arrange HTML-‐>SWF conversion services if required.
The following are examples of HTML layers covering part of the page. These examples are on page 3 (Google maps), page 9 (Twitter feed) and page 13 (RSS feed).
Partial page overlays are designed to fit into specific spaces left on the page, or on top of static assets (images, graphs) to replace them with a dynamic version. Because partial page overlays only cover a portion of the page any user interaction will only happen within the bounds of that overlay (in the case of interactive content). This makes them best suited for:
- smaller animated elements, particularly where these can be overlaid on the background without needing pixel-‐perfect alignment
- a block of scrollable text
- animated or interactive ‘blocks’ that fit into a space left on the page (such as the map, RSS and Twitter feeds above)
- other frequently-‐changing remote content, such as a stream of blog posts, an ‘also recommended’ feed, or a ‘latest offers’ list.
The following is an example of an HTML layer covering the entire page. This is page 1, and shows the page before and after the dynamic content animates in.
Note that most of the HTML layer is transparent, with the animated elements superimposed on the base layer taken from the PDF.
This is best suited for:
- A page with multiple animated elements, where it’s easier to create the content as a single animation than as multiple small ones
- A vertically scrolling page. This gives a 4-‐way navigation effect, where the user can scroll down to find more pages as well as swiping horizontally through the publication.
- An animated or interactive full‐page ad.
To add an on-page overlay to an publication:
- Create the content and place it in a ZIP file.
- Upload the ZIP file to the publishing site via the Files page, setting the Special Usage field to 'HTML Overlay'.
- Go to the Pages menu and select the page on which the lightbox should appear.
- Add an overlay and set the type to 'HTML'.
- Select the content file from the HTML ZIP dropdown.
- Set the Index File dropdown to the main HTML file within the ZIP. (Unless the content contains multiple HTML files, this will be the only option available in the dropdown.)
This is the same procedure as for adding a lightbox except for the overlay type used in step 4.
If the overlay content is interactive, the ‘Allows Interactivity’ checkbox must be selected; if the content is not interactive (such as a simple animation), it should be left unchecked.
Whereas with a lightbox the overlay should be drawn over the trigger area, here the area covered by the overlay defines where the content will be rendered.
The above assumes that the overlay content should be embedded with the publication. If the content should instead of streamed from a remote URL, then set the URL field and leave the HTML Zip File and Index File dropdowns set to None.
On-‐page content can also be set to be triggered in the same way as video overlays. By adding a trigger overlay for the content (that is, an additional overlay, with type Content, and with the ‘Trigger visibility of other content’ option checked), the HTML overlay is hidden until the trigger area is tapped.
Rendering and layout
The content renders on whichever area of the page the overlay is assigned to. The dynamic content may render slightly later than the base layer, such that the user sees the base page appear first, followed by the dynamic content. The length of delay is determined by the weight of the HTML content and the number of dynamic elements on the page.
Having content stream in will also affect the loading times, as data would need to be fetched from a server to be displayed. The connection status of the device will also come into play here as an offline device cannot display data from a remote server.
A recommended approach here is to make the dynamic content animate in. This can be done very simply with CSS transitions, and even a very short (200ms) fade-‐in effect makes the render process appear far more natural and smooth.
The ‘loader’ approach suggested for lightbox content can be used here as well.
As with lightbox content, the larger the HTML source, the slower it is to render on the page. Reducing the size of images and other assets is recommended.
The app uses thumbnail images of the pages at various points (depending on configuration and platform, in the table of contents, the graphical page navigator, and the search results). These are generated from the base PDF only. If the pages of the publication contain a significant quantity of dynamic content as HTML layers, then the thumbnails may not accurately match the page – for example, if the base PDF is blank with all the content provided dynamically, the thumbnail will be blank as well.
The production site supports upload of a set of replacement thumbnails, which can be used to prevent this. If this is needed, the YUDU production team can enable the feature for the app and provide details of how to use it.
Images in the HTML layer are low quality on a retina screen
With an iOS app, the content should be designed to render on a retina screen without loss of image quality. To achieve this, create the content at double the size of the reported size of the overlay in the overlay editor. For example, an A4 page, when covered completely by an overlay in the editor might have a size of 594px wide by 841px high. When creating the Dynamic Layer you need to double both these dimensions, so design the content for a frame that is 1188px wide by 1682px high. This ensures that the images and any other assets appear perfectly sharp on the higher-‐resolution screen.
The user can zoom the HTML layer independently of the rest of the page
To prevent this, add in a <meta> tag which forces the layer to scale to fit the overlay, and disables the ability to scale it independently of the page itself. This meta tag is:
<meta name="viewport" content="width = 100%, user-scalable =
At maximum zoom, the HTML layer loses its alignment with the surrounding page
The <meta> tag above addresses this issue as well.
The HTML content includes elements that should be positioned outside the visible area, but this is causing the overlay to render the content smaller than expected
Extra elements intended to be outside the visible area can cause the HTML content to be shrunk down until those extra elements fit inside the overlay area. To avoid this, either change the positioning of those elements, or set the content to hide any overflow.
To do this, set overflow : hidden on the main body of the content using CSS