Added the concept of meaningful spread

[HadrienGardeur]

In fixed layout publications, the spread can sometime be meaningful rather than decorative.

This new property is meant to convey this information and could be parsed from EPUB files where the spread is forced to both on specific items in the readingOrder.

This shouldn't force a spread to the user, but it could be useful for additional affordances and/or user settings.

I'm labeling this one as a draft PR for now since I'd like to open a discussion about the usefulness of this property and whether it belongs in the Divina profile or in core properties (since page has been moved there).

[HadrienGardeur]

@chocolatkey I'm sure you have some thoughts to share on this too

[mickael-menu]

How do you envision reading systems using this property in their settings or UI?

[HadrienGardeur]

How do you envision reading systems using this property in their settings or UI?

This would be an additional user setting that could trigger various behaviors.

One of the most common way of reading manga these days is to scroll through the pages with a fit on the width of the page. If this setting is enabled, a reading system could decide to display the entire spread side by side, displaying an indicator that the user can scroll horizontally as well in those cases.

I'm sure that there are various examples of how this is already implemented in various dedicated apps. @chocolatkey or @fillito might be able to give additional examples.

[HadrienGardeur]

Updated based on feedback from @mickael-menu that we should use camelCase for these properties.

To further illustrate what this is all about, here are two examples:

Non-meaningful spread

Meaningful spread

[HadrienGardeur]

Since it's been a month, I'm no longer labelling this one as a draft PR. We're skipping the next call but in the meantime, I'd love to get a thumbs up or down from stakeholders such as @mickael-menu @llemeurfr @qnga and @chocolatkey.

Since we haven't discussed this one as much, I'm putting it on a longer timer for merging (end of August) if we don't identify major disagreements in the process.

[llemeurfr]

I agree with the idea but there is a big typo in the writing: the definitions of breakScrollBefore and meaningfulSpread have been exchanged.

Also, the processing model could be more precise: what happens if there is a missing meaningfulSpread? I mena if (in the sample given) the right page has the property but not the left page? or the reverse? Are the properties valid only if they come as a pair?

[chocolatkey]

I think this is probably a better definition of the difference between spreads than what is available in EPUBs, because it's really about what the user will think should actually be seen as a spread. A lot of the time, EPUB metadata regarding spreads is either lacking, incorrect (from a user's perspective of what's most enjoyable to read), or determined using custom properties (such as, in Japan, the access-company metadata).

The reason why, at least for comics, it's important to know if a spread is meaningful or not, is because of how you then choose to display it on portrait screens (phones, which make up the majority of reading today). When a spread is not meaningful, it can be split into two pages, either vertically or horizontally. When it is meaningful, the reading app should be attempting to find a way to preserve the side-by-side nature of the pages. I think that if this is provided as a setting to the user, it should be something that is by default on, because most of the time it is irritating not to have a meaningful spread's content joined in the reader. I've attached an example of what a comic reader may do when a meaningful spread is displayed vertically.

Screen.Recording.20240722.114928.mp4

I do wish there was a way to add this property in a manner that made the logic for the reader more obvious, and make it impossible to create strange/invalid situations with (like only adding meaningfulSpread on a single page that's not a spread, which would be strange/undefined behavior, or three resources with it in a row which doesn't provide a clear beginning and ending to the spread, since you can have a single-page spread too). But I guess it will be:

- If meaningfulSpread == true, begin spread
- If the next resource also has meaningfulSpread == true, add the resource to the spread
- Goto beginning

This may sound a bit repetitive of other metadata that has been invented, but it makes me wonder if it would be better to have meaningfulSpread be left/right/center. But I understand keeping it simple. Maybe your intent, based on the examples, is that this property is always accompanying the page hint?

[HadrienGardeur]

I agree with the idea but there is a big typo in the writing: the definitions of breakScrollBefore and meaningfulSpread have been exchanged.

@llemeurfr I can't reproduce this issue, this is what I'm seeing in the current PR:

webpub-manifest/profiles/divina.md

Lines 229 to 232 in 4deda7e

	<dl>
	<dt>breakScrollBefore</dt>
	<dd>Specifies that an item in the reading order should break the current continuous scroll and start a new one.</dd>
	</dl>

webpub-manifest/profiles/divina.md

Lines 166 to 169 in 4deda7e

	<dl>
	<dt>meaningfulSpread</dt>
	<dd>Hint that the current resource should be presented in a spread to fully convey the meaning of its content.</dd>
	</dl>

Also, the processing model could be more precise: what happens if there is a missing meaningfulSpread? I mena if (in the sample given) the right page has the property but not the left page? or the reverse? Are the properties valid only if they come as a pair?

We don't have any processing models in our spec, because in a way, the toolkits are the processing model right now. This would of course need to change if we turn this into something bigger.

The processing model proposed by @chocolatkey should work, but ideally it's always best to explicitly indicate where each image should be positioned in the spread since you could have interspersed center spread items as well.
Without this hint, reading systems need to fallback to the reading progression and alternate accordingly.

This may sound a bit repetitive of other metadata that has been invented, but it makes me wonder if it would be better to have meaningfulSpread be left/right/center. But I understand keeping it simple. Maybe your intent, based on the examples, is that this property is always accompanying the page hint?

Correct, I'd rather keep the position in the spread and whether a spread is meaningful as two separate properties. There are good reasons to document page even if your publication doesn't contain meaningful spreads.

[qnga]

As Laurent noted, the processing model is not enforced by the specification. I think we could do that though: what about startSpread on the first resource of the spread? (there would be no room for confusion with the deprecated spread property, so meaningful is not necessary).

It would be more consistent with breakScrollBefore, in the sense that we're not talking about putting abreakScroll property into the two adjacent resource links.

If having spreads of more than two resources is ever something useful, I guess endSpread would make sense.

[HadrienGardeur]

I think we could do that though: what about startSpread on the first resource of the spread?

I don't think this reflects what the property is meant for.

EPUB gives content creator the false illusion that they have control over the presence of a spread, which we avoid doing.
The important piece of information here is the meaningfulness of displaying things in a spread.

Reading apps and users are always free to display pages in a spread if they want to, even when page and meaningfulSpread are missing. They're also free to dismiss these hints and just display one page at a time if they prefer doing so.

That's why I would shy away from any property that gives the illusion over having any control on spreads.

[qnga]

I understand information in publication formats mostly as a description of the publication rather than a rendering algorithm. With this in mind, there are no such things as meaningless spreads. Resource X does start a spread, no matter how a specific app with specific user settings chooses to render it. (Maybe I should have named the property startsSpread)

It's true that some EPUB properties are not purely descriptive. Maybe some RWPM properties too. I realize that the original presentation hints were really imperative (despite being called hints). It could be useful to decide which properties are requirements and which ones are preferred values, and settle on a general naming policy.

For instance, assuming that users are allowed to change the fit property, you could argue in the same manner that it gives authors the illusion of control. It might be better named preferredFit.

[qnga]

By the way, my original point was more about a solution to the possible issue of having only one resource with meaningfulSpread. If we put a property only on the first resource of the spread (no matter how it is named), we remove an opportunity for meaningless authoring. Generally, I think it's a good practice to avoid as much as possible offering opportunities for invalid combinations.

[qnga]

I've come to like Henry's proposal, though I would rename the center value.

There are good reasons to document page even if your publication doesn't contain meaningful spreads.

Could you elaborate?

[qnga]

Actually Henry called the property meaningfulSpread. I thought of something like page: left, right, alone (center) which would mean "if spreads are used, this page should be displayed on the left/on the right/alone. As this is clearly the simplest model you could devise, I'd like to understand what meaningfulSpread would enable us to do that we can't do with that.

[mickael-menu]

I guess without meaningfulSpread you can't know if two resources must always be displayed together, even if spreads are disabled in the reader. As page can be present as a hint only with EPUB.

With CBZ, authors "solved" this problem by having meaningful spreads as a single, wider bitmap file. If a spread must always be displayed for two resources, perhaps it should technically be a single resource. What is the benefit of splitting the spread into two resources?

[qnga]

We could interpret EPUB according to the specification

Although EPUB creators often indicate to use a spread in certain device orientations, the content itself does not represent true spreads (i.e., two consecutive pages that reading systems must render side-by-side for readability, such as a two-page map). To indicate that two consecutive pages represent a true spread, EPUB creators SHOULD use the rendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB content documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable.

In my understanding, indicating page: left/right on a meaningless spread is just useless. Inference from the readingOrder and readingProgression will be just fine. All what we need to document is exceptions. So in RWPM we could use page only on meaningful spreads and lonely pages (on the left, on the right, or normally fitted).

[HadrienGardeur]

To prepare for TPAC, I've done some additional work that gives us insights into this topic.

When talking with publishers, we see that the largest publishers in Europe default to:

• never including any information about spread placement
• or always including it, regardless of its importance

The EPUB spec advocates for something a little different:

To indicate that two consecutive pages represent a true spread, EPUB creators SHOULD use the rendition:page-spread-left and rendition:page-spread-right properties on the spine items for the two adjacent EPUB content documents, and omit the properties on spine items where one-up or two-up presentation is equally acceptable.

It's safe to say that there's a disconnect between what the spec tries to do and the reality of how content has been produced over the last 10 years.
I don't think that following the spec is the right move anymore, in fact I think that it would be best to tweak the spec in the next EPUB revision, to better align with what's out there.

Ideally, we'd need to extract this data over a large set of FXL EPUB to confirm that what we're seeing for comics/manga also extends to other types of FXL publications.

At the moment, it's not clear if publishers are capable of identifying meaningful spreads though. I'm going to continue interviewing publishers and try to reach out to Japanese publishers as well to better understand their situation (@chocolatkey do you think that you might be able to help with that?).

What's clear for me though:

• we need to align with the Apple Books behavior of displaying the cover on its own then alternating between left/right when there's no page property in the readingOrder
• I'm glad that we dropped spread, it's a complete dead-end both at the publication and at a resource-level

[HadrienGardeur]

This may sound a bit repetitive of other metadata that has been invented, but it makes me wonder if it would be better to have meaningfulSpread be left/right/center. But I understand keeping it simple. Maybe your intent, based on the examples, is that this property is always accompanying the page hint?

So in RWPM we could use page only on meaningful spreads and lonely pages (on the left, on the right, or normally fitted).

@chocolatkey @qnga That's pretty much what the EPUB spec says and what nobody seems to be doing right now. I think this should be a warning against going down the same road.