We sometimes get asked "do we follow the Adobe ePub best practices guide?". Our answer is "we have our own ePub best practices guides which have been formulated producing a lot more content than the authors of the Adobe guide.
The Adobe best practices was written two years ago. It specifically addresses an Adobe viewpoint of ePub and are showing their age, except where they apply to reader/device limitations. Having said that, most of the Adobe guide is pretty much simple common sense but oriented to trade novel type documents. There is a lot more content out there!
Because ADE (Adobe Digital Editions) is possibly the most widely distributed ePub reader to date, and the one with the best DRM support, we live with it and have to compromise ePub production to live with its limitations.
When we create ePubs for publishers new to ePub and devices we get the same set of questions about why e-pubs look and behave the way they do. Here is some practical information from the e-pub production coal-face.
1. I want some margins!
ADE - Black Interface - no device margin adjustments. Yes it is downright ugly and a bad reading experience. Text jammed against a black frame, no eye return target. However it is inadvisable to put left and right margins into your e-pub for just one reader on the desktop. When your e-pub goes to Stanza or another portable device in the future, the 2em margins will make an unrealistically narrow reading galley.
We recommend not adding left and right margins in the ePub stylesheet for standard trade books. There may be some presentation special cases where it can be used effectively.
2. Auto generated margin page numbers
Everyone hates the ADE generated numbers and how they overlap (and confuse) the content. Most customers ask for them to be removed or for a right margin to keep them away from the bodytext. Again this is inadvisable and requires non-standards compliant XSLT to be included in file to do it.
We recommend living with the auto page number and don't do any styling or modification in your ePub for any one reader or device.
3. Are my indexes linked?
There has been a lot of defeatism over the years with indexes and e-books. Some publishers just don't link them, often because digital production houses charge a premium for indexing (We don't.) The usual justification for excluding them is the search or find feature of the device can be used for the same job. Yeah! Sure.
If a print book is worth indexing, an e-book is even more valuable with index linking. In the master IGP:FoundationXHTML we always provide linked indexes with the following index options in the IGP:FLIP Formats on Demand processors:
- Remove index references - Yes/No. All page number links are just removed leaving a list of unlinked terms.
- Rename to Index sequence - Yes/No. Eg. "Index term 23-4, 67, 128" is turned into "Index term 1, 2, 3"
- Alpha facet for performance. A single Index is turned into multiple parts as ABC, DEF, GHI,... etc. This considerably improves limited device performance.
Of course none of this addresses the lack of a return function in ADE. So Index terms linked to an invisible (hardcopy) page number target gets the user to within 2-300 words as the index term, the same as a print book. Getting back to the term that is being referenced with ADE means looping through the TOC, scrolling into to the index location and clicking the next link. Other readers have link return functions.
We recommend maintaining linked indexes - facet large indexes into alphabet groups, and test on todays typical limited performance portable devices. Alternatively make sure your master XML/XHTML is linked to the page number reference and future ready. Don't hold your breath waiting ADE to do anything better.
4. Notes positioning and processing
Another linking problem is to and from book end-notes. For some academic or semi-academic work this has the same performance impact as not processing the index.
To address the issue of e-pub device performance, and different requirements for ebook and print, our standard practice with IGP:FoundationXHTML is to copy book end notes to their appropriate section and link them into the text from there. We always provide reverse linking for notes between the text reference and the note number.
Within the device, the loaded section file has all the back and forth links and the device is very responsive. This means the original book end notes can be left in place but unlinked or processed out during ePub creation. For print, the notes inserted at the end of the section are suppressed.
If notes are linked from the end of a book, every time a forward and back link is executed, the device has to load and unload section files, considerably slowing performance.
Our recommendation is move book end-notes to their section and link them from there. Make sure your Source XML still has the notes in the original place for future print production.
(Historical note: Back in '99-03 when we were producing hundreds of HTML / CD-ROM text books and other products, publishers were adamant that return linking was the job of the software, and there shouldn't be hard coded reverse links. Probably this was the correct approach. Who thought that a decade later someone would make a program without a link-return function.)
5. Footnotes
In IGP:FoundationXHTML footnotes are placed at the end of the paragraph that contains their reference. For print, they appear at the bottom of the page. For e-books they are processed to the end of the book section within which they occur, with return links to the reference. If there is also notes in the e-book the footnotes appear after the notes at the end of the section.
Our recommendation is show footnotes at the end of the section in which they occur with reverse links. They should still be available in the source XML to be used as roll-over pop-ups if and when devices support such features.
6. Original Pagination
Every now and then we get asked to produce e-books that show the original book pagination, usually with books that may have been extensively cited. We have a page-break element in FoundationXHTML and always include that in the XML for retrodigitized books. Where an e-pub is displayed paginated, it is best to leave footnotes in their original position, but still provide to and from links.
Our recommendation is to leave footnotes in their original position if you are showing original book pagination.
7. Cover presentation
We provide an elastic cover as standard. This means the cover scales with the resolution and size of the device window. This uses SVG. Some tackier readers still don't support SVG so there may be a problem with this approach.
Our recommendation is e-pub e-books look best with elastic covers, but it's all a matter of taste.
8. File Size - 100/300K limit
This is generally a reasonable recommendation, but is an unworkable constraint for some text books and reference material.
Our recommendation is to process for 300K uncompressed sections maximum (our applications test for this automatically) and if a book cannot be split apart appropriately, don't release it for limited performance devices, or editorialize the e-book content. IGP:FoundationXHTML has special XML elements to indicate limited device breaks. These decisions are captured in the XML and can be revised in the future as required.
9. Advanced Styling and Presentation
This is an e-pub area where you wont find many guides. Creating great looking and behaving ePubs is an art, and takes time. We have been producing advanced styling for trade e-pubs for over two years and our customers love them. It has significant impact with trade non-fiction and is often associated with branding, especially where colour is involved. The days of "one style fits all" e-book has got to go!
Our recommendation is don't dumb down your e-pubs , go for vanilla styling or buy into some automated conversion gizmo. Give them the same production values as your print outputs. It doesn't change the XML, just the stylesheets.
10. Aligning Content Horizontally
We produce for Faber and Faber, perhaps the largest poetry publisher in the world. Poetry is great content for e-books and mobile devices. However it has one layout property that ADE just doesn't support. Block centering. The centering rule for poetry is generally that it is centered on the page/galley on the longest lines. Long lines that wrap should have hanging style properties. To do this correctly CSS requires the CSS table visual display properties with margin left and right set to auto. ADE generates doubled content and screws this up pretty badly.
To compensate for this IGP:FLIP Formats on Demand has a special dumb-down function for ADE and poetry is displayed to the left instead of nicely in the center of the device. The source XHTML and CSS is still intact.
Our recommendation is a contradiction of the previous item. All rules are designed to be broken. When really needed for the value of the content, the end-user experience and to address significant device limitations, dumb down your e-pubs. But whatever happens don't loose the XHTML value for a device. They all go away eventually.
11. Summary
Content is an infinite continuum and lasts more or less forever. Devices are limited and come today and go tomorrow. The current crop of e-pub readers all have significant limitations, strange behaviours or are targeted at limited content types.
Our recommendation, don't let devices and applications define you e-pub business strategies. Don't create your e-pubs from an uncontrolled environment such as InDesign, you will have no future digital content strategy. Get the XHTML right, go for best possible presentation styling and behaviours, and live with device quirks and limitations. Evaluate your content in a standards compliant browser such as Firefox or Safari to see if it is presenting correctly.
I have been following ebooks (and for that computers since the early days of CPM and DOS. So, why cannot I get my epub ebook that reads in ADOBE to read in any other program. I can load it into FBReader and only get the table of contents. It will not load in MOBI. I guess it is a DRM problem. The main reason I want it to load in Mobi is so I can make notes and highlights. Any suggestions? I bought it from Fictionwise
Posted by: JLaan | 08 March 2010 at 09:24 AM
JLaan,
For sure this is the DRM issue. The OPF file that contains the manifest, spine and NCX is not encrypted, only the content itself (also embedded fonts are secured).
Your e-pub is DRM locked against ADE, and cannot be viewed on any other e-pub device let alone converting this to Mobi or any other format.
I hate to be the bad-news bunny here but there it is. I don't know if fictionwise has a returns policy. Probably not!
Current e-pub readers are very bad at notes and highlights, these things don't work so well with the text reflow stuff they are focusing on, but it will come shortly (maybe with iPad). Meanwhile we have to put up with vendor-specific e-book fulfillment where the dominant e-pub fulfillment software is Adobe ADEPT, and the reader software ADE is pretty useless (an opinion) for anything except the most simple novel.
Posted by: Richard Pipe | 08 March 2010 at 10:13 AM
If the Index is a list of possible search terms in the ePub, and all e-readers have a search function - instead of linking all of the search terms to an area of the book, is there a way to make selecting the index entry automatically launch a search for that term in the epub?
Posted by: J Myers | 28 July 2011 at 05:37 PM