Epub Revision - page-level layouts

[Nate the great]

Need for a means to convey page-level layouts and target multiple display surface sizes in a single publication. EPUB 2.0.1 lacks any way to specify page-level layouts or dynamically select different layouts based on considerations such as available display area and user-preferred font size. This is a barrier to supporting books with more complex information designs, as well as digital magazines, and even for trade books makes it harder to convey a “house style” (addressing this requirement was requested by the AAP in conjunction with its endorsement of EPUB in May 2008).

I think Adobe has already gotten a start on this one.

[charleski]

This boils down to a choice: CSS3 or XSL-FO.

Adobe has been in favour of XSL-FO for a long time. While it's more cumbersome to code than CSS, it's ultimately far more flexible and a far richer styling language. CSS3's paged media module is quite limited in comparison and has been stuck at working draft status for several years now, so it doesn't even have a finalised version to specify.

OTOH, while progress is somewhat glacial, web browsers are slowly moving towards support of CSS3 and web authoring will follow suit. From an implementation perspective, it's far preferable to allow those creating Reading Systems the ability to use the same renderer for both epub and web browsing functions on the same device.

Ultimately, I think CSS3 will win simply because it'll be easier to implement. Not a great reason, but possibly better than a situation in which Reading Systems implement an inconsistent subset of XSL-FO.

[kovidgoyal]

Thumbs down from me. I really don't want to encourage the creation of display size specific epubs.

In theory "support for multiple display sizes" sounds great. In practice people will make epubs that look great at a couple of sizes and look like crap everywhere else.

The whole concept goes against the grain of reflowability.

[dmikov]

Well that's why CSS might be a good call. n+ fixed layouts and one reflow. You don't like it, you change it to your favorite CSS. For drm of course readers should support custom CSS.

[HarryT]

Would page-level layouts include support for such things as "real" footnotes, headers and footers, and such like?

[Gearhead]

+1 for CSS. The standard should allow the user to completely replace the embedded stylesheet. This would allow better accessibility.

The iPad's iBook epub reading software is a good example of why user replaceable stylesheets are needed. The iBook software has fixed wide margins (3/4 inch on all sides), a pretty but useless static image of a book binding/cover on each page, and text justification that cannot be changed. Accessibility is reduced for low vision users since they cannot utilize the full screen area with large fonts and books with full justification have distracting rivers of white.

[charleski]

Originally Posted by HarryT

Would page-level layouts include support for such things as "real" footnotes, headers and footers, and such like?

Yes. It should allow much more as well, such as finer control of columns, marginal notes, etc. I think adding proper paged-media handling is pretty high on a lot of people's wishlists.

While I understand kovid's fear, I think it's misplaced. Both possible schemes generally promote a device-independent approach. It's possible to mess-up reflowability right now if you used fixed sizes, and that's one of the first things people learn not to do.

[kovidgoyal]

Originally Posted by charleski

While I understand kovid's fear, I think it's misplaced. Both possible schemes generally promote a device-independent approach. It's possible to mess-up reflowability right now if you used fixed sizes, and that's one of the first things people learn not to do.

Most people don't realize that it's possible to create fixed size layouts with HTML. With explicit support for fixed layouts, there are going to be a whole lot of people that will jump on that bandwagon simply because they ave built up lots of skills in fixed size design already and will be more comfortable with that.

[pdurrant]

There is a conflict here between the desire to control the layout by the publisher, and the desire to allow the reader to control the layout through the reading software.

For example, a publisher might like to specify one of two column text, depending on the width in characters (ems) of the current display. But equally, the reader might well want the choice to be a preference.

I think any page-size choice of formatting should be automatic by default, but that reader software should be able to provide the reader with the option to overrride the choice in the publication.

I have no idea how this would be done in practice with the current layout standards that have been mentioned in this thread.

[pdurrant]

Separate points.

I think it would be useful if the specification gave some guidance on how the page height should be interpreted by rendered. At the moment, sizing something based on page height is a bit hit and miss.

As Harry said, it would be wonderful to have some support in for footnotes. At the moment, I do footnotes with a link away to another page. I'd love to seem some specific coding that allowed footnotes to be identified by reading software, and either displayed in a pop-up window, or placed at the bottom of the page.

[charleski]

Originally Posted by pdurrant

There is a conflict here between the desire to control the layout by the publisher, and the desire to allow the reader to control the layout through the reading software.

For example, a publisher might like to specify one of two column text, depending on the width in characters (ems) of the current display. But equally, the reader might well want the choice to be a preference.

I think any page-size choice of formatting should be automatic by default, but that reader software should be able to provide the reader with the option to overrride the choice in the publication.

I have no idea how this would be done in practice with the current layout standards that have been mentioned in this thread.

This is more of an implementation issue than a standards one. A lot of it will be determined by the complexity and richness of the UI that is offered by the Reading System.

I think the best route is to encourage this to be done through modification of a user-level styling file. A RS that only allows a few basic modifications could then be enhanced by those willing to write more advanced css code.

Originally Posted by pdurrant

As Harry said, it would be wonderful to have some support in for footnotes. At the moment, I do footnotes with a link away to another page. I'd love to seem some specific coding that allowed footnotes to be identified by reading software, and either displayed in a pop-up window, or placed at the bottom of the page.

One important issue about footnotes: at present neither CSS3 nor XSL-FO explicitly support reflowing footnotes onto the next page. The common scenario in which there's a footnote on the 5th line from the bottom pointing to a note that's longer than 4 lines (for example) will break unless the RS is smart enough to realise that it needs to create a new footnote on the next page with the left-over lines. This needs to be mandated in the specification to make sure implementers don't mess it up. Using a pop-up windows instead would negate the problem (and is something I'd find preferable).

[Jellby]

Originally Posted by charleski

One important issue about footnotes: at present neither CSS3 nor XSL-FO explicitly support reflowing footnotes onto the next page. The common scenario in which there's a footnote on the 5th line from the bottom pointing to a note that's longer than 4 lines (for example) will break unless the RS is smart enough to realise that it needs to create a new footnote on the next page with the left-over lines. This needs to be mandated in the specification to make sure implementers don't mess it up. Using a pop-up windows instead would negate the problem (and is something I'd find preferable).

It does not need to be a pop-up if it lets you page/scroll the footnote area independently. In your scenario, the page would contain maybe 20 lines of main text and 4 lines of footnote; you could get the next page of the main text, dismissing the whole footnote, or page only the footnote, and you get the same 20 lines of main text, but the next 4 lines of the (long) footnote.

Things could get funny with footnotes inside footnotes inside footnotes, though.

Another related thing that could be worth considering is having some element that remains static while the rest of the book changes when paging, a bit like a header, but not for headers. For instance, a map or a diagram. In printed books you often have to turn the pages back and forth when your read a text that refers to a picture in another page (and it's sometimes inevitable, if the text that refers to it is more than one page long). Wouldn't it be nice if you had the possibility of saying "during this whole passage, keep this image fixed on screen while scrolling/paging the text".

[pdurrant]

Originally Posted by Jellby

Another related thing that could be worth considering is having some element that remains static while the rest of the book changes when paging, a bit like a header, but not for headers. For instance, a map or a diagram. In printed books you often have to turn the pages back and forth when your read a text that refers to a picture in another page (and it's sometimes inevitable, if the text that refers to it is more than one page long). Wouldn't it be nice if you had the possibility of saying "during this whole passage, keep this image fixed on screen while scrolling/paging the text".

Oh, what a good idea!

[DaleDe]

Originally Posted by pdurrant

Separate points.

I think it would be useful if the specification gave some guidance on how the page height should be interpreted by rendered. At the moment, sizing something based on page height is a bit hit and miss.

As Harry said, it would be wonderful to have some support in for footnotes. At the moment, I do footnotes with a link away to another page. I'd love to seem some specific coding that allowed footnotes to be identified by reading software, and either displayed in a pop-up window, or placed at the bottom of the page.

I do not think footnotes should be tied in any fashion to this initiative. Footnotes need to be considered on their own merit and implemented without regard to an page boundaries or page level layouts. We do need the footnotes to be defined in the standard but the implementation should not be defined or forced to a page level scheme without regard to screen display sizes.

Dale

[Xenophon]

I would like to see the standard mandate support for footnotes within footnotes (within footnotes, within...). And similarly for endnotes.

Specifically, I don't want the situation we have with Terry Pratchett novels in EReader format, where 2nd and lower level footnotes are lost because the document format cannot support them.

Xenophon