An unofficial way to create fixed-layout EPUB publications is to include images (excluding SVG) directly in the package document spine. This method of creating fixed layout pages is not commonly used, however, as images are not allowed in the spine without fallbacks, so in most cases it is simpler just to embed the image in either an XHTML or SVG fixed layout page.
When using images in the spine, no fixed-layout metadata is set as it will cause validation errors (e.g., because the required dimensions can only be determined from XHTML and SVG). It may even cause reading systems not to render the publication.
A related problem is that by not being able to specify fixed-layout metadata, this method offers little control over the presentation of the pages. It also comes with severe accessibility problems.
Putting images in the spine is no different than putting XHTML or SVG documents in the spine —
itemref element is used to refer to where the image is declared in the manifest:
<package …> … <manifest> <item id="pg01" src="pg01.jpg" media-type="image/jpeg"/> … </manifest> <spine> <itemref ref="pg01"/> … </spine> </package>
If the preceding example were validated with EPUBCheck, however, it would result in an error because JPEGs are not supported in the spine.
To make the publication valid, a fallback to either an XHTML or SVG document must be specified on the manifest entry.
<manifest> <item id="pg01" src="pg01.jpg" media-type="image/jpeg" fallback="pg01-fb"/> <item id="pg01-fb" src="pg01.xhtml" media-type="application/xhtml+xml"/> … </manifest>
If a reading system does not support images in the spine, it can now render the fallback XHTML page instead.
Images in the spine are the least accessible way of creating a fixed layout.
There is no way to provide either alternative text or extended descriptions for the images without having to provide these through a fallback. As a result, if the reading system supports rendering the images, there will be no way for users to access the text alternatives (i.e., users are typically not provided the option to view fallbacks; the reading system automatically selects which to display). The result is that users of assistive technologies will hear nothing when the publication is read.
Also, without any assurance that users can reach the alternative, it is also not possible to make a claim of WCAG conformance, even if the alternative would be conforming.
To avoid the cost of creating a backup for every fixed layout page, a single fallback document that simply says the publication is not supported by the reading system might be used. This practice is basically as useless to readers as not providing text alternatives.
Similarly, there may not be a one-to-one correlation between fixed layout pages and a text serialization of the content. In this case, it will not be possible for each page to have a fallback without confusing the reader somehow (e.g., if a series of pages fall back to the same text serialization, the reading system will keep rendering the text every time a page is turned).
The use of multiple renditions was intended to help solve the need for alternative serializations, but there is virtually no support for the specification.
For these reasons, XHTML and SVG fixed layout pages should always be preferred.