Fixed-layout rendition properties section seems super unclear about publ-cg HOT 4 OPEN

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?

from publ-cg.

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.

from publ-cg.

from publ-cg.

@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.

from publ-cg.