scrolled-continuous in EPUB 3.1: any restrictions?

[murata2makoto]

I am wondering if there are any restrictions on the use of scrolled-continuous.

Consider content documents CD0, CD1, CD2, CD3, CD4, CD5, and CD6. Here CD2, CD3, and CD4 are reflowable, while CD0, CD1, CD5, and CD6 are fixed layout.

In the meta element, we have rendition:flow=scrolled-continuous. But itemrefs in the spine specify rendition:layout-reflowable for CD2, CD3, and CD4, and specify rendition:layout-pre-paginated for CD0, CD1, CD5, and CD6.

In my understanding, CD2, CD3, and CD4 should be concatenated and scrolled together. But CD0, CD1, CD5, and CD6 are rendered separately. If my understanding is correct, we shouldn't say "the EPUB Publication represented by the given Rendition should be presented as one continuous scroll from spine item to spine item (except where locally overridden).

Moreover, I think that we should require that CD2, CD3, and CD4 have the same page-progression direction.

[mattgarrish]

It's could be changed to:

"and all reflowable EPUB Content Documents should be presented as one continuous scroll from spine item to spine item (except where locally overridden)."

How could the page progression direction change in a continuous flow? Wouldn't that require somehow reverting on itself?

[murata2makoto]

When CD2 and CD3 and specify different page progression directions, I don't think that they can be combined and scrolled.

[mattgarrish]

Right, that's what I was asking. Not whether someone might try, but technically isn't it an impossibility.

Can that be covered with a statement like this one we have for pre-paginated content:

Reading Systems must ignore the page progression direction defined in pre-paginated XHTML Content Documents.

If only the spine p-p-d is respected, it's not a problem, correct?

[murata2makoto]

Actually, CD2 and CD3 are reflowable.

[mattgarrish]

Yes, I'm asking if a similar statement for scrolled-continuous would clarify, not that it's covered by the quote. So something like:

"Reading Systems MUST ignore the page progression direction defined in EPUB Content Documents when presenting them as a continuous scroll."

[murata2makoto]

I see. Sorry.

I think that the scroll direction (i.e., horizontal or vertical) depends on the p-p-d.

[mattgarrish]

Do you have a preference for solving this @murata0204 ?

Would a statement like I suggested above in the description of the scrolled-continuous value work, or is more or something else needed?

[murata2makoto]

A sequence of content documents should be concatenated and scrolled
together, if

• every content document is reflowable and has the same
  page page progression direction,
• the immediately preceding content document is either 1) non-existent or 2) pre-paginated, or 3)
  reflowable but has a different page progression direction,
• the immediately following content document is either 1) non-existent or 2)
  pre-paginated, or 3) reflowable but has a different page progression
  direction.

The direction of scroll is determined by the page progression direction of the content documents

The above requirement is unnecessarily complicated because of the mixture of RTL ppd and LTR ppd, which I would like to prohibit. But we might already have such data, especially when people used single-page reflowable content documents instead of FXL content documents.

I am afraid I know too little about how pagination is implented and how it interacts with scrolled-continous. I would like to hear feedbacks from implementors.

[mattgarrish]

@GarthConboy @danielweck any perspective on this issue with scrolled-continuous and ppd?

[iherman]

I would wonder whether there is a need for such situations. In abstract, I could imagine it. Eg, there are a number of bilingual books where, say, French and English are presented side-by-side; I could imagine this in other combination. But I do not know whether this is a realistic need. @murata0204, Japanese is right-to-left (in come cases): is there a perceived need for such cases? We do have contacts in Hebrew, Japanese, Indian/Pakistani (for Urdu), etc: is it something for which there is a real need or not? Is it something we would postpone?

I do not have the answer, just asking questions...

[murata2makoto]

I would wonder whether there is a need for such situations.

Need for scrolled-continuous? Or, need for the mixture of RTL-ppd and LTR-ppd?

[iherman]

On 29 Aug 2016, at 13:35, MURATA Makoto notifications@github.com wrote:

I would wonder whether there is a need for such situations.

Need for scrolled-continuous? Or, need for the mixture of RTL-ppd and LTR-ppd?

—

I meant the latter.

[murata2makoto]

Some printed books use the mixture of RTL-ppd and LTR-ppd. When EPUB3 was being created, the i18n subgroup of the EPUB WG considered it. The conclusion is that it is too difficult to provide a sensible UI and that we should allow a single value for the page-progression-direction attribute of the spine element.

But, in my understanding, we have not explicitly prohibited the mixture of RTL-ppd and LTR-ppd. For an image-only HTML, I do not think people bother to specify CSS only for specifying the ppd. As a result, we might have the mixture.

In the case of scrolled-continuous, I think that we need either RTL sequences or LTR sequences of reflowable content documents within a single EPUB rendition, but not both.

[mattgarrish]

It's not technically impossible to account for changes, but it requires the RS to inspect every document in the scroll to determine whether there are changes and provide navigation from one set to the next. That's probably unrealistic.

I think this is just a failing of continuous scrolls in that there's no way to create separate scrolls. What you want is to be able to group one set of documents as having one ppd and another as having a different, but turning on scrolling is binary.

Similar to a note about RSes ignoring ppd overrides above, what if we just state that: "Authors MUST ensure that all EPUB Content Documents in a continuous scroll have the same page progression direction."

Unless we expect support for changes in direction, the solutions have to be limiting.

[murata2makoto]

What I want is, for example,

FXLCD0, RTLCD0 ,RTLCD1, FXLCD1, RTLCD2, RTLCD3, FXLCD2

where RTLCD0 and RTLCD1 are concatenated, and RTLCD2 and RTLCD3 are concatenated, or

FXLCD0, LTRCD0 ,LTRCD1, FXLCD1, LTRCD2, LTRCD3, FXLCD2

where LTRCD0 and LTRCD1 are concatenated, and LTRCD2 and LTRCD3 are concatenated

But what happens when we have RTLCD0 followed by LTRCD1? Should the result be undefined?

[mattgarrish]

The same thing that happens when you reach the end of any scroll. You'd swipe to the right the first time to move to the LTR document and then when you reach the end of that scroll you'd have to swipe to the left. Continuous scrolling requires navigation along two axes if the entire rendition isn't one scroll.

It's probably going to be counter-intuitive to the user, but it's no different than if they weren't in a scroll.

[murata2makoto]

That's why the EGLS subgroup concluded that one direction is good enough.

Although pre-FXL EPUB might contain single-page image-only LTR-ppd HTML content documents
in the RTL-ppd spine, we can safely assume that this is not the case for post-FXL EPUB. Let alone the case for scrolled-continous.

What authors need is simple. The reflowable XHTML content documents within a spine have the same ppd. Some of them are concatenated when scrolled-continuous applies. The ppd direction controls the scroll direction. That is, vertical scroll for LTR, and horizontal scroll for RTL.

What should implementors do when they encounter RTL-ppd reflowable followed by LTR-ppd reflowable and scrolled-continuous applies to them? I don't know. @GarthConboy @danielweck ?

[danielweck]

Thoughts:

From a reading system perspective, mixed continuous scrolling modes (i.e. vertical and horizontal) is very hard to implement for reflowable content (perhaps easier for fixed layout, e.g. 2-axis magazine style navigation).

Note that Readium currently only supports vertical continuous scrolling mode, that is to say: only for documents / spine items in horizontal writing mode. Horizontal scrolling would be necessary for vertical writing mode such as some Japanese text (typically in RTL also).

Page progression direction is actually a separate matter. For example, a vertical continuous scroll view can be used for a sequence of RTL or of LTR documents, what matters here is the horizontal writing mode.

Problems start occuring in terms of UI/UX design when mixing LTR-RTL and/or VWM-HWM documents within the same spine. Mixing HWM-LTR (e.g. English) and HWM-RTL (e.g. Arabic) documents is in fact possible within a vertical viewport, because both language scripts are compatible with a top-down layout (no bidi-like challenges). But there are combinations that just don't work, especially HWM-VWM mixes. This seems like an intractable problem.

[mattgarrish]

Is there a case here for deprecating/removing this feature?

These might be niche cases, but if there are intractable flaws then it doesn't seem like a good idea to retain. It was a late addition during the integration in 3.0.1.

[mattgarrish]

Or, alternatively, cripple the ability to create these variations by disallowing spine overrides when set, and remove rendition:flow-scrolled-continuous as a spine override.

We could then leave guidance that this feature is only designed for documents that all share the same ppd and scrolling direction.

[murata2makoto]

Daniel wrote:

Page progression direction is actually a separate matter. For example, a vertical continuous scroll view can be used for a sequence of RTL or of LTR documents, what matters here is the horizontal writing mode.

Agree! both Hebrew documents and Japanese vertical writing documents have the RTL ppd. I believe that vertical scroll is used for the fomer. Horizontal scroll is used for Japanese vertical writing.

[danielweck]

For reference: http://www.idpf.org/epub/31/spec/epub-packages.html#layout-property-flow

[TzviyaSiegman]

Proposed language from Makoto for note: It is expected that a future version of this specification will provide more information about RS behaviors for scrolled-continuous.