Spreads and having control over them

[HadrienGardeur]

This is based on my gap analysis between EPUB 3.2 and WP: w3c/wpub#176 (comment)

In EPUB, there's a concept of spreads (mostly through the package rendering vocabulary) where two resources can be displayed next to one another, and where we also give the author and UA control over how resources are displayed.

This is mostly used in Fixed Layout publications and is useful for comics, kid books and textbooks among others.

[HadrienGardeur]

Since this is extremely useful for comics and there are a lot of them on the Web today, we might need to think about this carefully (it could make sense for WP).

For EPUB4, this is absolutely required by trade publishers.

[danielweck]

I agree about EPUB4, I am wondering about WP.

A couple of remarks:

A typical use-case for two-page spreads in EPUB3 fixed-layout (aka pre-paginated) publications is when left-page and right-page contain content that must be ; by design ; presented together side-by-side (such as an illustration and its accompanying text in a children's book, or a full-bleed illustration seamlessly crossing over the page boundary).
That being said, the separation into two distinct HTML documents for content that is meant to always be displayed side-by-side is arguably idiosyncratic in digital publishing, because it would make a lot more sense to bundle the left and right "page" markup into a single document (twice the width). In fact, the two-document approach can cause problems such as bad "stitching" (i.e. visible pixel-imperfect boundary between the left and right illustrations), or slightly out-of-sync rendering of the left and right pages (e.g. mismatched animation timing due to separate document contexts, or flickering / flashing during page transitions).
I do appreciate that this is inherited from paper printing, where all pages have the same physical dimensions. Furthermore, I imagine that not all EPUB3 reading systems support publications with mixed page sizes, which makes two-page spreads a reasonable pragmatic technical design decision.

A typical FXL use-case for one-page display is when a publication's content document is designed to be rendered on its own, such as a cover image, preface, acknowledgements, or any other kind of material that presents nicely as one fixed-layout page (whereas the rest of the publication can flow equally-well as a sequence of single pages or two-page spreads, depending on presentation context such as screen size, aspect ratio, etc.). In this case, content creators have at their disposal the EPUB3 FXL metadata which controls whether single pages should be right or left-aligned (typically simulates a blank page at beginning / end of printed book, or anywhere mid-stream too), or even to occupy the center position in the reading system's viewport.

[dauwhe]

The FXL spread metadata was an attempt to reconcile the divergent existing solutions from Amazon (which wanted spreads as a single html file) and Apple (which wanted spreads split into two files).

I would predict that browsers would never implement such a thing natively. Authoring content in such a way is also problematic—what would a screen reader do with a sentence that was split across two separate HTML documents? Such metadata might be useful in EPUB4, but I don't thing general WPs should inherit this baggage.

[HadrienGardeur]

For comics/manga using exclusively images, I really think that having spreads in WP would be useful as well.

Now that we have an Audiobook TF, maybe it's time to start a BD/Comics/Manga TF as well?

[TzviyaSiegman]

I think the first question to answer regarding whether duplicating FXL properties is needed for WP is whether this is an issue on the Web. Can one produce BD/Comics/Manga on the Web today without this info? If yes, then we should not need the additional information. This might be an example of metadata needed for EPUB 4 but not WP.

[HadrienGardeur]

Sorry @TzviyaSiegman but I don't think that's a good way of having this discussion. Everything we'd like to do in this group can be done on the Web through a mix of JS, CSS and HTML. But some of these things could be handled better or in a different way: that's why this WG exists in the first place.

Comics and audiobooks are quite different from other publications that we've been discussing so far:

• they may primarily use images and audio instead of HTML (although for comics we'll probably have both)
• they're very often distributed today like WP (with a mix of streaming and caching)

Comics can be massive publications (hundreds of megabytes) and we shouldn't restrict the ability to use spreads with images strictly to a packaged version (EPUB4) that might take a long time to download and potentially take all your available storage as well.

[dauwhe]

For an example of some of the difficulties we would face here: readium/architecture#72

[HadrienGardeur]

@dauwhe I was on the call that discussed this and this is a problem on the Web as well as it's been pointed out (between two iframes).

[llemeurfr]

You may find the Readium FXL overview interesting. It details the issues we are facing during FXL implementation in reading apps (especially mobile apps).