fallenpegasus: (Default)
[personal profile] fallenpegasus
Some thoughts on composing laying out ebooks:
- DONT put a separate additional title page at the beginning. The user just saw the title in the renderer's UI when they selected the book. Separate title pages are archaic: an ebook will never be stripped or rebound.
- DONT put the copyright info, publication info, "printing" info, legal disclaimers, boilerplate, colophon, etc at the beginning. Put it at the end.
- The only exception is you MAY put the ToC at the beginning.
- if there is a ToC, each line of the ToC MUST include the name of the chapter or section, and SHOULD contain a short (3 lines or less) description
- if the book has a ToC or an Index, each entry MUST hyperlink internally to the part of the book they reference.
- DONT put footnotes or notes or citations at the "bottom" of the "page", or at the end of the chapter, or worst of all, at the end in a "Notes" section.
- DO put footnotes, notes, and citations inline, and hint them to the renderer, so it can fold them, to be expanded at the user's touch.
- Hint to the renderer, that the first time the book is displayed, it SHOULD open to either the introduction, or to the starting text of chapter one.
- DONT try to force the renderer to waste pixels on margins. Let a renderer running on a mobile, eink, or small tablet run the text right up the side of the display. Let a render running on a desktop or large tablet use it's own margins. It *always* knows better than your art and layout editor.
- Renders SHOULD ignore, subvert, and frustrate attempts by the publisher's art and layout editor to force margins. The render and the user know better, always.
- DONT render body text or header text as an image, unless it's a visual poem (for example, the poems in "Alice in Wonderland"), but even then, see if you can hint it to the renderer instead.
- DONT render a drop capital as an image.
- If the book contains images, the image data SHOULD be the highest resolution and color depth the renderer can display. If you don't know what the renderer will be, the image data SHOULD be at least 1024x768.
- Each image data rectangle MUST be one and only one image or photograph.
- DONT put margins in the image rectangle
- Each image SHOULD completely fill the ebook display when rendered. Renderers SHOULD heuristically clip margins and rotate images to completely fill the display surface.
- Comic books and graphic novels will have a different set of rules and requirements, which I will write up another day.

Date: 2017-05-24 10:25 pm (UTC)
From: (Anonymous)
> The only exception is you MAY put the ToC at the beginning.

Amazon has gone back and forth on this. For a while last year they were requiring that the ToC be at the beginning (scammers were playing games with it). Now that's just "recommended" rather than "required". I would strongly advise leaving it at the front in case they change their mind again.

> DONT put footnotes or notes or citations at the "bottom" of the "page", or at the end of the chapter, or worst of all, at the end in a "Notes" section.

Notes with bidirectional hyperlinks (bidirectional is critical here -- there needs to be a reverse link from the note back to the exact location you came from) work much better, whether located at the end of the chapter or at the end of the book. Folding schemes are guaranteed to break on the (many) ebook readers that don't support Javascript at all (in particular, no Kindle model supports Javascript).

> DONT render a drop capital as an image.

I would recommend avoiding drop capitals at all, but at present the only remotely portable way of rendering them across the different ebook platforms is as images. No, CSS won't work for this. Not the CSS supported by common ebook readers, anyway.


Date: 2017-05-24 11:53 pm (UTC)
From: (Anonymous)
I kinda suspect here that you haven't actually spent a lot of time looking at the guts of how current ebooks actually work. Like most guts, they're not pretty.

There's a common misconception that ebooks are "just HTML", which is kinda true. Sorta. If you squint. And ignore the XML navigation baggage off to the side and the peculiar quirks lurking around the edges -- e.g., that the first entry in the EPUB zip file is "special" -- the first entry must be a specific file, must be uncompressed, etc.

The problem is that when people hear this they think "HTML5, ECMAScript 6, CSS3", when what you actually get is XHTML 1.1, no Javascript, and whatever subset of CSS2 the reader's manufacturer chose to implement (said subset not being the same across manufacturers, or even across models from the same manufacturer). The situation is a lot closer to the web in 1997 than the web in 2017.

EPUB3 was supposed to help with this, but wound up drowning under its own weight. Every possible wish list feature got rolled in, without anyone bothering to write any actual code to implement that feature. As a result it's been more than five years since the EPUB3 spec was published and there still isn't even a reference implementation, much less any commercial adoption. At this stage pretty much everyone except the EPUB3 committee (who are understandably reluctant to admit that their baby is ugly) has written it off.

So. EPUB2. XHTML 1.1. Portions of CSS 2. No Javascript. That's what we have. Amazon uses its own format (which is undocumented, because of course it is) but has free beer tools that can readily convert EPUB2 to that format. Likewise Apple's iBooks (though, unlike Amazon, iBooks *can* open a plain vanilla EPUB2 file).

The manufacturer formats do have their own fancy features, and of course these are all mutually incompatible (again, think of web browsers in 1997, only worse). Some people try to hack around this with CSS media queries and the like, but that way lies madness. If you don't mind maintaining two separate "code bases" for the book. Apple's iBooks format lets you get quite fancy, but you're going to be using Apple tools to build the book, Apple devices to read it, and the Apple store to sell it. Amazon Kindle format is the same story, only the output isn't as pretty. :-)


fallenpegasus: (Default)
Mark Atwood

May 2017

 1234 56
21 2223 24252627

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 26th, 2017 12:02 pm
Powered by Dreamwidth Studios