Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is page-spread-center a synthetic spread or not? #1929

Closed
mattgarrish opened this issue Nov 21, 2021 · 8 comments · Fixed by #1950
Closed

Is page-spread-center a synthetic spread or not? #1929

mattgarrish opened this issue Nov 21, 2021 · 8 comments · Fixed by #1950
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation Topic-FXL The issue affects fixed layout documents

Comments

@mattgarrish
Copy link
Member

The definition of page-spread-center is:

The rendition:page-spread-center property specifies the forced placement of a Content Document in a Synthetic Spread.

But this doesn't really tell you anything, not to mention it would be impossible to force a centered document into a two-page spread. Then after the property definitions comes this:

The rendition:page-spread-center property indicates to override the synthetic spread mode and render a single viewport positioned at the center of the screen.

This is much clearer about what to render, but isn't this completely contradictory to the definition? Is there a spread if it overrides spread mode? How are we forcing the document into a spread at the same time we're overriding spreads?

If there's only a single centered viewport, that's not the same as merging the two halves of a spread to make one dual-page spread.

I'd hazard a guess the property would make more sense if it were called "rendition:page-center", since it seems to have little to do with spreads other than to override them.

I'm not sure how best to make sense of the current contradictions, though. All I can think of off the top of my head is to maybe make a separate subsection to explain "page-spread-center" so it's less confusing with the -left and -right properties. Dropping the current definition about forcing a document into a synthetic spread would also help.

@mattgarrish mattgarrish added the Topic-FXL The issue affects fixed layout documents label Nov 21, 2021
@wareid
Copy link
Contributor

wareid commented Nov 24, 2021

Can I second this as the person who just had to write the test for this? The wording is awkward as it would suggest a RS should not change the page size to fill the screen, instead just render the same viewport and move it to float in the centre of a suggested synthetic spread.

In reality its behaviour is more like rendition:spread none, or maybe page-spread-none.

@mattgarrish
Copy link
Member Author

it would suggest a RS should not change the page size to fill the screen

Ya, the reading system spec has this note:

The presence of rendition:page-spread-center does not change the viewport dimensions. It does not indicate that a Reading System must create a viewport with the size of the whole spread. This is important so that the scale factor stays consistent between regular and center-spread pages.

It's just a centered viewport. Is this really different from how fixed layout pages that aren't in a spread are presented?

@wareid
Copy link
Contributor

wareid commented Nov 25, 2021

We have the tests now to actually confirm, but as far as I know, any implementation I've seen of page-spread-center just treats the viewport as if it's not in a spread.

This might be a new issue on it's own, but I realized while working on the tests for the rendition:spread meta properties that we also define some spine properties for spread that are only MAYs, but have no equivalent in the RS spec, so it's easy enough to write tests for them but the behaviour is strikingly similar to page-spread-*.

It might be too ambitious to try to refine this section in both specs but working on the tests kind of demonstrated how weird all of this behaviour is.

@mattgarrish
Copy link
Member Author

Should we deprecate page-spread-center rather than try to make sense of it and make it an alias for the spread-none override so reading systems know how to handle it?

@mattgarrish
Copy link
Member Author

For reference, what started me going on this was trying to title example 49, which says in its text:

Note that it is not necessary to specify the spread-none override on the centered plate, as the rendition:page-spread-center property already specifies semantics that dictates that synthetic spreads be disabled.

Making it an actual alias to spread-none already fits with this prose.

And going back to the original FXL doc, it further confirms this is only an override:

This document defines one additional property, rendition:page-spread-center, which indicates that the synthetic spread mode should be overridden such that instead of two adjacent viewports, a single viewport must be used, and positioned at the center of the screen.

That's enough confirmation for me that we're not losing some needed use case. We don't need two ways to turn off spreads, especially one that sounds like it's turning on a spread when it isn't.

The "centering" aspect is maybe something we can add to the spread none definition, although I can't imagine why a reading system wouldn't center a single content display area.

@mattgarrish
Copy link
Member Author

I've bumped into a note I can't fully comprehend in trying to implement this change:

The presence of rendition:page-spread-center does not change the viewport dimensions. It does not indicate that a Reading System must create a viewport with the size of the whole spread. This is important so that the scale factor stays consistent between regular and center-spread pages.

What is the "size of the whole spread" if there isn't a spread? I'm also not sure what a "regular" page is that it's being compared to.

My best guess is this is saying that you don't have to fill the whole screen, in which case I don't think it needs retaining since that's also consistent with spread-none.

@wareid
Copy link
Contributor

wareid commented Dec 1, 2021

My best guess is this is saying that you don't have to fill the whole screen, in which case I don't think it needs retaining since that's also consistent with spread-none.

I think this is what it is trying to say as well, and I totally agree, it's most consistent to point to spread-none behaviour than try to determine some special appearance for page-spread-center.

@dauwhe dauwhe added the Agenda+ Issues that should be discussed during the next working group call. label Dec 8, 2021
@wareid wareid linked a pull request Dec 8, 2021 that will close this issue
@iherman
Copy link
Member

iherman commented Dec 10, 2021

The issue was discussed in a meeting on 2021-12-09

  • no resolutions were taken
View the transcript

2. Is page-spread-center a synthetic spread or not? (issue epub-specs#1929)

See github issue epub-specs#1929.

See github pull request epub-specs#1950.

Wendy Reid: i just got through writing the tests for all the FXL rendition properties, which lead to a question about page-spread-center.
… this is a spine property that is not meant to override spread behaviour, but that the page should be centered in the viewport.
… but this doesn't seem to be what is happening in practice.
… rather, the observed behaviour seems to be identical to spread none.
… we've discussed in the issue, and mgarrish came up with the idea of making page-spread-center an alias of spread none.
… and not to deprecate page-spread-center.

Brady Duga: not sure why page-spread-center is confusing. Imagine you are doing a synthetic spread, but you want one specific page centered in the middle of the screen. That's how you would tell the RS to do that..
… spread none sounds like you've turned off spreads completely.

Wendy Reid: an additional level of oddness was finding out that you can put page spread properties on spine level items as well.

Brady Duga: spread none and spread center mean different things, because spread none doesn't tell you where to put the page.
… and yes, it is confusing that you can put this on a spine item (you can also alternate portrait and landscape on spine level items as another weird way of interacting with spreads).

Dave Cramer: is there a concern that this could affect the relative size of pages as you go from spread, to non-spread, and back to spread?.

Brady Duga: i can't see people really doing this.
… one potential use case is if one of your content documents is already a spread, so you want to disable synthetic spreads for that one only.

Shinya Takami (高見真也): in Japan we use spread-center for the cover pages in many many cases, so making spread-center a depreciated feature would not be acceptable.
… aliasing it to spread none is okay.

Wendy Reid: right, so we won't deprecate page-spread-center.
… this might be the sort of thing we need to test out.
… when the page appears in the center of the viewport, i think there is a change in the page size.

Dave Cramer: i'm not comfortable deciding this until we have more info on whether we need to better define how a RS should position the viewport when you use page-spread-center or spread none as an override of a synthetic spread epub.

Wendy Reid: agree that the FXL properties section could use some visual aides.
… we can put this off for tonight.

Brady Duga: if we end up keeping page spread then we need to fix this definition.

Wendy Reid: yeah, definitions in that section are not very good.

Dave Cramer: it was a long time ago that we wrote those, we were balancing against implementations that already existed at the time (amazon, apple).

@mattgarrish mattgarrish removed the Agenda+ Issues that should be discussed during the next working group call. label Dec 17, 2021
@mattgarrish mattgarrish added Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation EPUB33 Issues addressed in the EPUB 3.3 revision labels Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EPUB33 Issues addressed in the EPUB 3.3 revision Spec-ReadingSystems The issue affects the EPUB Reading Systems 3.3 Recommendation Topic-FXL The issue affects fixed layout documents
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants