page progression direction in FXL content documents

[dauwhe]

https://w3c.github.io/epub-specs/epub33/rs/#spine

Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents. The page-progression-direction attribute defines the flow direction from one fixed-layout page to the next.

1. The EPUB page-progression-direction attribute is only defined in the package file, and thus can't occur in XHTML.
2. CSS has the concept of page progression, which is defined via the principle writing mode. See https://www.w3.org/TR/css-writing-modes/#principal-flow.
3. The CSS direction property (which we've discouraged), as well as the HTML dir attribute, define an inline base direction, but interact with other CSS properties to determine the page progression, as mentioned above.

Do we actually want to say this? Say we have an Arabic FXL document, but the page-progression-direction attribute on the spine is missing. A reading system is allowed to choose which PPD to use, by arbitrarily guessing, or by examining the dc:langauge in the package file, but cannot observe that the page progression of every XHTML Content Document is RTL?

[dauwhe]

Ah, this seems slightly simpler:

• If text is laid out in horizontal lines, the page progression is the same as the inline base direction.
• If text is laid out in vertical lines, the page progression is the same as the block flow direction.

[murata2makoto]

Unless this description is broken, I do not see any reasons to fix it. Your rewrite does not look great to me, since it does not use technical terms defined in CSS Writing Modes.

[dauwhe]

Unless this description is broken, I do not see any reasons to fix it. Your rewrite does not look great to me, since it does not use technical terms defined in CSS Writing Modes.

I'm not proposing a rewrite yet. I do think the spec text is a bit ambiguous. We seem to be saying that the EPUB page-progression-direction attribute operates independently of anything defined in individual pre-paginated XHTML content documents.

[murata2makoto]

We seem to be saying that the EPUB page-progression-direction attribute operates independently of anything defined in individual pre-paginated XHTML content documents.

I am quite sure that this happens very often in Japanese manga.

I feel very uneasy to touch this para.

[iherman]

Do we actually want to say this? Say we have an Arabic FXL document, but the page-progression-direction attribute on the spine is missing. A reading system is allowed to choose which PPD to use, by arbitrarily guessing, or by examining the dc:language in the package file, but cannot observe that the page progression of every XHTML Content Document is RTL?

I guess this is a matter of what the 'default' behavior of page-progression-direction is; in this sense, this issue may be the same as #1482.

Regardless, I indeed do not understand why the spec text says:

Reading Systems MUST ignore the page progression direction…

I think it would be perfectly reasonable to say MAY instead of MUST (and that would not create a backward incompatibility problem and maybe emphasize in the sentence that this is the case when page-progression-direction is either missing or its value is default.

@murata2makoto I do not think that such a change would invalidate any manga RS behavior.

[mattgarrish]

Doesn't trying to infer a page progression direction from a fixed layout page lead back to some of the problems outlined here: #95 (comment)

Not saying "MUST NOT" is the right answer, but this seems like a complex problem we probably can't give a completely satisfactory answer for.

If we're only trying to leave open the option to inspect the content, though, could we make this more of a precedence rule:

Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents when the page-progression-direction attribute is set to "ltr" or "rtl".

[iherman]

Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents when the page-progression-direction attribute is set to "ltr" or "rtl".

Is this for FXL only or for all EPUB-s?

[toshiakikoike]

I think it's better to leave this part as it is.

Most Japanese comic epubs are following;
https://github.com/toshiakikoike/comic-epub-sample/tree/master/GiveMyRegards-to-BlackJack1
OPF：<spine page-progression-direction="rtl">
Content Document：not set "writing-mode"(then default is horizontal-tb)

I think it is clearer that it is written as follows(same as 3.2).

Reading Systems MUST ignore the page progression direction defined in pre-paginated XHTML Content Documents. The page-progression-direction attribute defines the flow direction from one fixed-layout page to the next.

[bduga]

I think there is a clarity issue here at the very least, since we are using "page progression direction" and "page-progression-direction" to mean different things. It is also a little confusing coming after the section on default, which leaves it to the reading system to choose the direction when the value of page-progression-direction is default. Are we explicitly saying the RS can choose, but can't use the content to make the choice? We might consider clarifying with something like:

"If page-progression-direction has a value other than default, Reading Systems MUST ignore any directionality computed from the content."

If we really wanted to clean this up, we could create an explicit processing model for PPD instead of the unordered collection of conformance statements.

[wareid]

I think there is a clarity issue here at the very least, since we are using "page progression direction" and "page-progression-direction" to mean different things. It is also a little confusing coming after the section on default, which leaves it to the reading system to choose the direction when the value of page-progression-direction is default. Are we explicitly saying the RS can choose, but can't use the content to make the choice? We might consider clarifying with something like:

"If page-progression-direction has a value other than default, Reading Systems MUST ignore any directionality computed from the content."

If we really wanted to clean this up, we could create an explicit processing model for PPD instead of the unordered collection of conformance statements.

Completely agree, @mattgarrish and @bduga would it be ok to ask for some recommended text? Then we can discuss in a meeting about the clarification.

[bduga]

@wareid I think my recommended text was:

"If page-progression-direction has a value other than default, Reading Systems MUST ignore any directionality computed from the content."

Or did you mean for a full blown processing model?

[iherman]

The issue was discussed in a meeting on 2022-02-17

List of resolutions:

• Resolution No. 1: Adopt Brady's suggested text in issue 1483, close issue 1483.

View the transcript

2. page progression direction in FXL content documents (issue epub-specs#1483)

See github issue epub-specs#1483.

Dave Cramer: I was a little puzzled by language in the spec around this.
… there may be a clash of terminology, i.e. page-progression-direction attribute from the package doc, CSS's own documentation about page progression, etc..

Brady Duga: I think there was some proposed text at the end of the discussion.

Wendy Reid: "if page progression direction has value other than default, RS must ignore page progression computed from the content".

Dave Cramer: if you don't put page progression direction in package, but you obviously have rtl content then it seems strange to say that the RS can't figure that out.
… so I would support the proposed text.

Murata Makoto: sounds reasonable to me.

Proposed resolution: Adopt Brady's suggested text in issue 1483, close issue 1483. (Wendy Reid)

Dave Cramer: +1.

Wendy Reid: +1.

Shinya Takami (高見真也): +1.

Brady Duga: +1.

Toshiaki Koike: +1.

Matthew Chan: +1.

Masakazu Kitahara: +1.

Resolution #1: Adopt Brady's suggested text in issue 1483, close issue 1483.

[iherman]

See PR #1999. This issue will be closed if and when that PR is merged.