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.

[HadrienGardeur]

It's been a few months and I haven't seen any argument convincing enough against this approach:

• while in theory, page should only be used for meaningful spreads in EPUB, that's not the way this is currently used by content creators
• therefore, we need to re-align with current practices: page is only a hint about spread placement, not an indication that spreads should be used/forced
• the current controls for spreads in EPUB are irrelevant since they're mostly ignored by RS
• at a publication-level, these controls are even dangerous and can be misused by content creators (a number of EPUB publications force the both value at a publication-level even though the spreads are not meaningful)
• at a resource-level, these controls are barely used and allow some very weird combinations

With this new value that only conveys the importance/meaningfulness of one specific spread at at time as a boolean, we're moving away from the footgun approach of the EPUB spec.

[qnga]

I still haven't seen a processing algorithm supporting both meaningfulSpread and page:left/right. The mobile toolkits support only the latter while Jiminy's work seems to support only the former.
Until proven otherwise, my feeling is that supporting both would result in a messy specification. Can you provide such a processing algorithm or confirm that page:left/right would not be used any more (even as a placement hint) because it's hardly compatible?

[mickael-menu]

Yes the processing model is still missing, there's a discussion to be had whether it should be part of the specification or a separate document.

Can you provide such a processing algorithm or confirm that page:left/right would not be used any more (even as a placement hint) because it's hardly compatible?

IMHO you should still use page: left/right with meaningful spreads as it is usually fixed in this case. This can be derived from the reading progression but the user can change it.

[HadrienGardeur]

Until proven otherwise, my feeling is that supporting both would result in a messy specification. Can you provide such a processing algorithm or confirm that page:left/right would not be used any more (even as a placement hint) because it's hardly compatible?

I don't see any compatibility issue, they're expressing two different information: placement and meaningfulness/importance.

EPUB tried to cover both with the same property somehow and failed in the process. I don't see how replicating EPUB's failure would help in any way.

Yes the processing model is still missing, there's a discussion to be had whether it should be part of the specification or a separate document.

Correct, we don't have processing models/rules in our current RWPM specs, which is a good reason to keep this separate from this PR and open a dedicated issue.

There are only two options IMO, where in both case we require the presence of page and:

• meaningfulSpread on both resources in a spread
• or meaningfulSpread on at least one resource of a spread

[qnga]

Regardless of the location of the processing model, it doesn't make much sense to me to add a property that we don't know yet how to process. As I understand it, that's the way the W3C proceeds to avoid ungrounded specifications: they define the processing model and even require some implementations before adopting a specification. Besides, I think publication formats are meant to be rendered, which makes them driven by expectations about user experience. Some of you might disagree because I don't feel like this is the way this proposal was introduced.

I probably don't sound very helpful because this is not my proposal: I really don't know how we could properly process this meaningfulSpread property along with the page property given a readingProgression. That's why I've been asking for the layout algorithm for months.

[HadrienGardeur]

We're not trying to "invent something new" here. This is already something that exists in multiple comics/manga reader, but they're supporting this feature with proprietary formats, simply because there isn't a standard format for expressing that kind of information right now.

That's very much in line with what we've done in Readium over the years: we stick to real-world use cases and try to get rid of as much fluff as we can in the process (that's how we ended up giving the boot to controls over spread and orientation for example).

If you take the example posted by @chocolatkey in #103 (comment), the manifest would look something like that (I'm assuming that this is an RTL publication):

"readingOrder": [
  {
    "href": "page1.avif",
    "type": "image/avif",
    "properties": {
      "page": "left"
    }
  },
  {
    "href": "page2.avif",
    "type": "image/avif",
    "properties": {
      "page": "right",
      "meaningfulSpread": true
    }
  },
  {
    "href": "page3.avif",
    "type": "image/avif",
    "properties": {
      "page": "left",
      "meaningfulSpread": true
    }
  },
  {
    "href": "page4.avif",
    "type": "image/avif",
    "properties": {
      "page": "right"
    }
  }
] 

In the video, the user settings are set to:

• use continuous scrolling
• and only display meaningful spreads

Without the meaningful spread hint, all pages would be fit to width, displayed below one another and the true spread would be very hard to read (which is often the case in manga readers, since they're missing that information when they rely on a CBZ or EPUB based workflow)

[llemeurfr]

I agree with @qnga: The lack of a processing model in Readium specs is NOT a feature, it is a missed opportunity (and I'm trying to avoid this pitfall in https://github.com/readium/annotations#4-best-practices-for-reading-systems).
In this case, the possible presence of 1 or 3 meaningfulSpread indications in sequence must be dealt with.

And there are still questions with the implementation of spreads in mobile reading systems:

• what are the possible user settings? (I spotted in a previous comment "use continuous scrolling", "only display meaningful spreads". Is there also "display spreads in landscape mode"?)
• how is "page" interpreted in portrait mode? skipped, I suppose.
• how is "page" interpreted in landscape mode if "use continuous scrolling" is selected by the user?

[HadrienGardeur]

The lack of a processing model in Readium specs is NOT a feature, it is a missed opportunity

IMO this discussion has little to do with this specific PR, because if we go down that road, it makes no sense to only cover the processing model for meaningfulSpread and nothing else (thank god we never tried to cover the processing model for what we had in advanced Divina presentation hints).

What are the possible user settings? (I spotted in a previous comment "use continuous scrolling", "only display meaningful spreads". Is there also "display spreads in landscape mode"?)

This is also outside the realm of what we usually do because different reading apps could have different takes on this.

If I had to design an app, I would use:

• a toggle switch between paginated and continuous scrolling reading modes
• and three values for spreads: only meaningful spreads, always and never

I've already illustrated in my previous message how the combination of "continuous scrolling" and "only meaningful spreads" could behave.

Apple Books is a good example of a reading system where the spreads are always displayed, but the user can switch between paginated and a continuous scrolling reading modes.

how is "page" interpreted in portrait mode? skipped, I suppose.
how is "page" interpreted in landscape mode if "use continuous scrolling" is selected by the user?

This has nothing to do with orientation.
As I've said before in this thread, page is strictly used as a placement hint:

• If you decide to never display spreads, it won't be used.
• If you decide to always display spreads it'll be used to place the image correctly in the spread.
• If you decide to only display meaningful spreads, it'll be used to place the image correctly in meaningful spreads and ignored if the spread isn't meaningful.

[HadrienGardeur]

To further illustrate how a reading system could behave based on the example shared in #103 (comment), here are a few examples of the way the layout would be handled:

First of all, a few reminders for this example:

• the readingProgression is set to rtl
• and the page placement looks like this:
  • Page 1: Left
  • Page 2: Right
  • Page 3: Left
  • Page 4: Right

To illustrate this example, we'll use a drawSpreads preference available in the Preferences API with three different values: always, never and meaningful.

"drawSpreads": "always"

| 1 | x |
| 3 | 2 |
| x | 4 |

We place the first resource in a spread and then we start a new spread whenever:

• we encounter a new resource where page is set to right (this would be left for an LTR progression) or center
• or two consecutive resources where page is set to left

"drawSpreads": "never"

| 1 |
| 2 |
| 3 |
| 4 |

With this setting, spreads are completely ignored.

"drawSpreads": "meaningful"

| 1 |
| 3 | 2 |
| 4 |

With this setting, spreads are ignored unless we encounter meaningfulSpread.
If this property is documented on the first page of the spread (the right one for RTL, the left one for LTR) and the spread contains two resources, then we draw a spread.

[qnga]

If you decide to never display spreads, it won't be used.
If you decide to always display spreads it'll be used to place the image correctly in the spread.
If you decide to only display meaningful spreads, it'll be used to place the image correctly in meaningful spreads and ignored if the spread isn't meaningful.

That's the piece of information I lacked. That makes some sense now. I feel like you're trying to recycle some EPUB properties whose meaning would be slightly shifted though. Let me start from scratch in order to try to get things more obvious.

I don't think that page is really a useful placement info. There's nothing about placement that the right readingOrder and readingProgression cannot convey in a far more straightforward way. Actually, I think of it more as a way to make a (meaningless) spread with a blank page.

As I mentioned in #104, there are two possible readings of page: center in the spread: always mode:

• The page is a spread on its own, so we fit it as we do with double spreads. If there's text on it, authors should be well-aware of the behavior to achieve scale consistency. With such a reading, the name center is meaningless. As the EPUB spec was very unclear and evolved, that's not a reason for discarding it though.
• The page should be sized as any other page (not spread). So, assuming the resource dimensions (viewport dimensions or image dimensions) are the same as in other resources.
  I believe that page: center is mainly used for covers whose intrinsic sizes are identical to those of any other page, so I'll assume the first reading in what follows.

Unless you consider you might have a meaningful spread with a blank page (I can't see the point), meaningfulSpread followed by page: center or (in LTR) page: left is forbidden. So there would only be one legal page value after meaningfulSpread : that's page: right in LTR, and it's pointless. So page does not provide any valuable information in the only meaningful spreads mode. That's evidence for page not being used in practice to convey page position but information about spreads with a blank page.

It looks to me that we need to express three different things:

• this resource starts a meaningful spread
• this resource precedes/follows a blank page
• this resource is a spread on its own

Wouldn't it be simpler and clearer to have a unique property to convey everything about that?
spreadInfo: startsMeaningfulSpread, followsBlankPage, precedesBlankPage, isStandaloneSpread
The authoring rule and the processing could be quite obvious: if a resource starts a meaningful spread, the next one must not have a spreadInfo property set. If it has one anyway, ignore it. We could call the property spreadInfo to insist on its descriptive value, but even if we call it spread there is no place for confusion with the Epub spread property as there is no single common value. On the contrary, we would go far away from the EPUB properties (no more common properties) so things could be even clearer.

[qnga]

Thinking more about it, I'm not even sure we need precedesBlankPage. In printed books, blank pages used to be used for (book/chapter) content to be started on the same page as the cover: on the right in LTR and, I guess, on the left page in RTL. If I'm not mistaken, that'll always falls under the followsBlankPage case. There might also be some technical name for this that I'm not aware of. We would then truly be able to describe books with semantics, the simple processing model describing how they are rendered in the different modes.

[llemeurfr]

@HadrienGardeur in your example of use of spreads=meaningful, it seems that you make the hypothesis that the user has selected something like "1 column" in his app, or the screen is not large enough to handle a spread by default (e.g. smartphone in portrait mode). What if the user has selected "2 columns" or the screen is large enough to handle 2 columns or more?

[llemeurfr]

Shouldn't spreads=always be spreads=recommended to respect the user's ultimate decision and the device screen's constraints?

[mickael-menu]

@llemeurfr The idea is to have the navigator always draw the spreads when requested, no matter the viewport's size. This way the host/app can use its own set of constraints to switch the Preferences API from single pages to spreads (viewport breakpoints, portrait vs landscape, etc.). This also opens the ability to always draw the spreads, but have another setting to "fit" a single page on small screens, letting the user scroll to reveal the rest of the spread.

[HadrienGardeur]

Just to be clear, I think a number of people are conflating:

• hints provided by the publication (page, meaningfulSpread)
• with preferences available through the Preferences API

The only thing worth saving from the EPUB spec IMO is page. Everything else is either dangerous and/or ignored by RS (spread, orientation or layout when applied to a resource).

What I've described above for spreads is a preference available through the Preferences API and it has nothing to do with spread in EPUB. It might be even clearer to call this drawSpreads as @mickael-menu has correctly pointed out that this is all about drawing spreads and nothing to do with orientation, screen size or preference for fitting content in the screen.

[HadrienGardeur]

To reply to @qnga:

That's the piece of information I lacked. That makes some sense now. I feel like you're trying to recycle some EPUB properties whose meaning would be slightly shifted though.

That's not the case, I'm only saving page with all its existing values in EPUB, the rest goes to the trash.

It looks to me that we need to express three different things:

• this resource starts a meaningful spread
• this resource precedes/follows a blank page
• this resource is a spread on its own
  Wouldn't it be simpler and clearer to have a unique property to convey everything about that?
  spreadInfo: startsMeaningfulSpread, followsBlankPage, precedesBlankPage, isStandaloneSpread

I would state things differently:

• this resource starts a meaningful spread if you want to draw only meaningful spreads (meaningfulSpread)
• and this is where you should place the resource if you want to display it in a spread (page)

I think you're using the wrong definition for page: center when you say:

this resource is a spread on its own

I think that with this approach, you're implying the use of spreads (something that a publication should not and cannot enforce), whereas center means that when spreads are drawn/displayed, the resource should be on its own.

You're also assuming things about the dimension of this resource that you shouldn't be doing. It can potentially be of any size/ratio.

I also fail to see how using three new properties is clearer than two, especially with something as widely used and understood as page.

[qnga]

I think that with this approach, you're implying the use of spreads (something that a publication should not and cannot enforce), whereas center means that when spreads are drawn/displayed, the resource should be on its own.

I thought of it more as a way to describe the publication as a printed publication, where there are always spreads. It may not be appropriate though. Isn't the Fixed layout mode (as opposed to scroll for webtoons) something coming from printed books and strongly tied to them?

You're also assuming things about the dimension of this resource that you shouldn't be doing. It can potentially be of any size/ratio.

I might have been for the sake of simplicity. I don't think that not doing so would change anything to the demonstration though.

I also fail to see how using three new properties is clearer than two, especially with something as widely used and understood as page.

page something widely used and understood? I thought the whole point of meaningfulSpread was that nobody understands the EPUB page property, supposed to be used to mark meaningful spreads (it's been quite clear in the spec for a while).

Besides, I'm not talking about three properties, but a single one with all suitable values and only them, enforcing incompatibility between property values in case of nonsensical or pointless combinations. That's my whole point: a model powerful enough to express all our needs but just that powerful, not more.

[HadrienGardeur]

page something widely used and understood?

You're completely right that there's a disconnect between the spec and how it's used, but since we're not going to change everyone's mind (and millions of EPUB files), the best way to deal with this is to re-align the EPUB specification with the way this is actually used.

There are basically two use cases out there:

• publications that never document page and expect things to behave like in Apple Books
• publications that document page on every single resource, because they don't want the reading system to guess

I'm proposing to also align Readium with what people expect, not the cryptic meaning hidden deep in the EPUB spec where only experts take a look.

I thought the whole point of meaningfulSpread was that nobody understands the EPUB page property, supposed to be used to mark meaningful spreads (it's been quite clear in the spec for a while).

Not exactly. The EPUB spec barely mentions anything that sounds like the concept of "meaningful spreads" and it's inferred rather than explicitly stated.

The idea is to make the concept front and center and turn it into a declarative hint rather than an inferred processing rule.