-
Notifications
You must be signed in to change notification settings - Fork 61
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
page progression direction in FXL content documents #1483
Comments
Ah, this seems slightly simpler:
|
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 |
I am quite sure that this happens very often in Japanese manga. I feel very uneasy to touch this para. |
I guess this is a matter of what the 'default' behavior of Regardless, I indeed do not understand why the spec text says:
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 @murata2makoto I do not think that such a change would invalidate any manga RS behavior. |
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:
|
Is this for FXL only or for all EPUB-s? |
I think it's better to leave this part as it is. Most Japanese comic epubs are following; I think it is clearer that it is written as follows(same as 3.2).
|
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 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. |
@wareid I think my recommended text was:
Or did you mean for a full blown processing model? |
The issue was discussed in a meeting on 2022-02-17 List of resolutions:
View the transcript2. 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. 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 Murata Makoto: sounds reasonable to me.
|
See PR #1999. This issue will be closed if and when that PR is merged. |
https://w3c.github.io/epub-specs/epub33/rs/#spine
page-progression-direction
attribute is only defined in the package file, and thus can't occur in XHTML.direction
property (which we've discouraged), as well as the HTMLdir
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 thedc:langauge
in the package file, but cannot observe that the page progression of every XHTML Content Document is RTL?The text was updated successfully, but these errors were encountered: