Fixed-layout rendition properties section seems super unclear

I’ve been trying to understand why a lot of our samples (for Readium CSS) had page-spread-* spine overrides in reflowable and after reading the specs, I’m even more confused.

Our first assumptions was that they were meant for fixed-layout, the title of the section being “Fixed-layout properties” indeed. But then, when reading subsections, reflowable kicks in.

My educated guess is that we’re talking about reflowable documents (HTML files if you wish) in fixed-layout publications (EPUB file, i.e. a collection of HTML files although this is a simplistic representation). Fact is I can’t tell for sure though, and it looks like quite a significant amount of authors can not as well.

Sure there is

This section defines a set of metadata properties to allow declarative expression of intended rendering behaviors of Fixed-Layout Documents in the context of EPUB 3.1.

But then…

The rendition:page-spread-left, rendition:page-spread-right and rendition:page-spread-center properties apply to both pre-paginated and reflowable content, and they only apply when the Reading System is creating Synthetic Spreads.

So OK, content is used there, not documents. But then…

EPUB Content Document A Publication Resource that conforms to one of the EPUB Content Document definitions (HTML or SVG). An EPUB Content Document is a Core Media Type Resource, so can be included in the EPUB Publication without the provision of fallbacks.

While it is my understanding that Fixed-Layout Publication should have been used if it should apply to the Publication itself:

EPUB Publication A collection of one or more Renditions that conform to this specification, packaged in an EPUB Container. An EPUB Publication typically represents a single intellectual or artistic work, but this specification does not circumscribe the nature of the content.

And then:

Fixed-Layout Document An EPUB Content Document directly referenced from the spine that has been designated pre-paginated in the Package Document, as defined in The rendition:layout Property [Packages 3.1]. The dimensions to use for rendering Fixed-Layout Documents are defined in Fixed Layouts [Content Docs 3.1].

Sorry but I happen to find myself in some sort of loop in which we can’t tell for sure whether it applies to fixed-layout publications with reflowable contents inside it or it applies to reflowable publications as well.

If it applies to rendering behaviors of Fixed-Layout Documents and not the Publication, should I ignore the parts related to reflowable as well?

The page-spread-* properties predate fixed layouts in EPUB: http://www.idpf.org/epub/30/spec/epub30-publications.html#sec-itemref-property-values

They're also obviously important for fixed layouts, but the fixed layout properties were all defined with the rendition: prefix. That led to confusion about why only those two properties (-left and -right) weren't prefixed, and why there was an exclusive rendition:page-spread-center. The decision was to make aliases so that all fixed layout properties can be used as rendition:*.

I agree that it's confusing that they're listed under the fixed layouts section, as they really belong under the general properties. They stayed with the FXL properties when we merged that spec into publication during the 3.0.1 revision, but could use a rethink.

But I'm not sure I understand what distinction you're making about publications and content. The properties define the placement of content documents (which is all that spine itemrefs can be) in a spread, as per this paragraph:

When a Reading System renders a Synthetic Spread, the default behavior is to populate the spread by rendering the next EPUB Content Document in the next available unpopulated viewport, where the next available viewport is determined by the given page progression direction or by local declarations within Content Documents. By providing one of the rendition:page-spread-left, rendition:page-spread-right or rendition:page-spread-center properties [Rendition Vocab] on a spine itemref element, an Author may override this automatic population behavior by forcing that document to be placed in a particular viewport.

It doesn't matter if the publication is all fixed layout, all reflowable or some mix of the two. When it comes to placing the specified spine item into the active spread, the author's intention is that it go in the slot specified.

Does that make sense, or am I misunderstanding your confusion?

Well I must admit that my confusion probably lies in conversations with several people, including RS implementers and vendors, in which we couldn’t really agree if it was just for fixed-layout or not. Some people thought it wasn’t scoped to fixed-layout, and should apply to reflowable too, but were not very sure, others were surprised it wasn’t just for fixed-layout.

So having this under the “Fixed-layout Properties” section probably added to this confusion and mention to reflowable surprised me a little bit (like trying to make sense of something so I ended up checking the Terminology).

Thanks for the clarification, I indeed saw that part but once it was too late (when trying to make use of the terminology for this particular section). Moving it outside this particular section would indeed help, especially as at least my personal experience so far – can’t speak for others, obviously – has been diverging interpretations from RS implementers and vendors alike, which can in turn create interop issues – fortunately, this is not the case there.

In terms of my own layout experience: it would be very nice if this could somehow be brought into the publication as ’toggled’ rule based on page id… Some fixed layout books work best as individual L & R pages with the occasional ‘spread’ inside the book. Right now, you can only choose one global format or the other.

On Dec 6, 2017, at 3:12 PM, Jiminy Panoz notifications@github.com wrote:

Well I must admit that my confusion probably lies in conversations with several people, including RS implementers and vendors, in which we couldn’t really agree if it was just for fixed-layout or not. Some people thought it wasn’t scoped to fixed-layout, and should apply to reflowable too, but were not very sure, others were surprised it wasn’t just for fixed-layout.

So having this under the “Fixed-layout Properties” section probably added to this confusion and mention to reflowable surprised me a little bit (like trying to make sense of something so I ended up checking the Terminology).

Thanks for the clarification, I indeed saw that part but once it was too late (when trying to make use of the terminology for this particular section). Moving it outside this particular section would indeed help, especially as at least my personal experience so far – can’t speak for others, obviously – has been diverging interpretations from RS implementers and vendors alike, which can in turn create interop issues – fortunately, this is not the case there.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/publ-cg/issues/20#issuecomment-349760411, or mute the thread https://github.com/notifications/unsubscribe-auth/AMwGgIQy4kmfcEgBJQnIRyDRVwjaQi3Dks5s9vU6gaJpZM4Q3zAH.

@artbyrt As far as I can tell, at least depends how viewports/pages are handled (esp. with web views for native apps/iframes for web apps). But that doesn’t tell the whole story, though.

Further details: fixed-layout can have a lot of issues in terms of performance (swiftness of rendering) because of 1. images rendering and caching, 2. complex absolute positioning (esp. when every word is positioned absolutely i.e. InDesign output), 3. extra resources e.g. fonts, 4. explicit viewport enforcing, 5. touch handling/features, etc., and 6. to make matters worse, everything must be rendered at once (we don’t have any “under the fold” concept there). That’s not an epub problem per se, it applies to web browsers as well (and the rendering engines most apps borrow).

In other words, I would not hold my breath there: the RS’ performance budget is quite constrained (it must work on low-entry devices and even native code is tough there) and making it work well and fast is already quite a feat for simple FXL publications – some apps still can’t get it right on middle-entry devices released in 2017 for instance e.g. HD images crashing the app on popular Android devices. And when those problems are solved, there is no room left for such features. Which is also why “SHOULDs” in the spec are often not implemented.

On a related note, that’s why RS don’t polyfill paged media, because it would imply writing an entire rendering engine in JavaScript. And that just can’t work on mobile devices because the impact would be nasty – for the record, we already have to deal with non-latin publications which takes 5+ seconds to render in web browsers, on powerful devices, when left completely untouched and -epub-writing-mode is used in the CSS… that can turn into 13+ seconds on mobile with minimal handling if you don’t use tricks to make it faster.

w3c / publ-cg

Fixed-layout rendition properties section seems super unclear #20