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

Already on GitHub? Sign in to your account

Precedence of the PPD attribute at the spine and the PPD implied by the content document #205

Closed
GoogleCodeExporter opened this Issue Mar 24, 2015 · 17 comments

Comments

Projects
None yet
1 participant
3.4.12 of EPUB Publications introduces the page-progression-direction 
attribute and further provides a note about other mechanisms, most 
notably the writing-mode and direction properties within HTML content 
documents, for indicating the page progression direction. 


http://idpf.org/epub/30/spec/epub30-publications.html#sec-spine-elem

However, nothing about the precedence rule is provided.  Thus, it 
is not clear which one wins and how the synthetic spread should 
be created

Unfortunately, there are no good solutions.

First, consider an EPUB publication for Japanese or Taiwanese manga 
such that each page is represented by a simple HTML document containing 
an image element and nothing else.  Since such HTML documents 
typically lack CSS, the default writing-mode and direction properties apply, 
and thus the left-to-right page progression is implied for these HTML 
documents.  However, note that this implied PPD is never used, since each HTML 
represents a single page.  The PPD attribute at the spine specifies 
right-to-left.  
The RS should exhibit the right-to-left behaviour and construct the synthetic 
spread by using the right page first.  In other words, the PPD at the 
spine should win. 

Second, consider a reflowable EPUB document representing a Japanese or 
Taiwanese novel in vertical writing or Hebrew/Arabic book.   HTML content 
documents in such an EPUB publication have CSS stylesheets and the implied 
PPD is right-to-left.  The RS should exhibit the right-to-left behaviour and 
construct the synthetic spread by using the right page first.  Even if the 
spine 
lacks the PPD attribute or specifies left-to-right, the PPD specified in 
content 
documents should win.

One could argue that the PPD at the spine should be right-to-left in the second 
case, and the PPD at the spine should always win.  However, some books in Asia 
have *both* right-to-left and left-to-right directions.  This may sound crazy, 
but 
is very natural when a book has two chapters: one (e.g., advise about education 
in general) in vertical writing and another (e.g., a collection of math 
exercises) 
in horizontal writing.  Thus, we cannot easily say that the PPD at the spine 
should win.

There were a lot of discussions about this topic in the EGLS Taipei meeting.  
In 
the end, everybody agreed that we need more experiences for handling 
combinations of right-to-left and lef-to-right, partly because the UI would 
be very confusing.


Original issue reported on code.google.com by eb2m...@gmail.com on 17 Feb 2012 at 1:07

I forgot to mention style switching.  HTML allows alternate stylesheets, and 
EPUB3 even adds "Alternate Style Tags".  Thus, switching from vertical writing 
to horizontal writing, and vice versa is possible.  However, this switching 
does not change @PPD at the spine.  ;-(

Original comment by eb2m...@gmail.com on 18 Feb 2012 at 12:59

[deleted comment]
Yet another thing I forgot to mention.  Different resources in the fallback 
chain for a resource may have different PPDs.  The interaction between such 
PPDs and  the spine-level PPD becomes even more complicated.  ;-(

Original comment by eb2m...@gmail.com on 19 Feb 2012 at 5:57

[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
[deleted comment]
This issue is still tricky, but I am not aware of any real examples that hit 
this issue.  So, it would be ok if we make a bit of improvements and stop there 
for 3.0.1.

We now have FXL.  It is quite obvious that the PPD of FXL HTML content 
documents is irrelevant.  I propose to add this observation and do nothing else.

Original comment by eb2m...@gmail.com on 8 Mar 2013 at 12:06

Does it make more sense to include this text in the rendition:layout section, 
noting that when pre-paginated is set it doesn't matter. Or would it make more 
sense in the page-spread-* section.

I'm assuming because this is tied to fxl that it doesn't also need to go up in 
the spine, where it would be a bit out of context.

Original comment by mgarrish on 15 Apr 2013 at 7:37

I agree that the section for rendition:layout is a better place.

Original comment by eb2m...@gmail.com on 15 Apr 2013 at 10:24

In the teleconf on 2013-08-22, it was agreed to make the PPD specified at the 
spine element take precedence.  As far as we know, all implementations do so.

Original comment by eb2m...@gmail.com on 23 Aug 2013 at 10:22

As far as I know CSS does not give page progression direction, therefore I also 
think that PPD specification in the spine take precedence.

Original comment by ori@helicontech.co.il on 24 Aug 2013 at 6:25

72hour passed:

https://groups.google.com/forum/#!searchin/epub-working-group/205/epub-working-g
roup/uuPCzyx0-SE/Qj9PyFuHjv4J

Original comment by markus.g...@gmail.com on 19 Sep 2013 at 8:09

Specification has been updated:

https://code.google.com/p/epub-revision/source/detail?r=4739

The following paragraph was added to the spine element definition following the 
pargaraph already detailing PPD:

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.

I think this is the best place to note this, as it is referred to from other 
sections (e.g., rendition:spread has a note directing people to this element 
for information about ppd precedence). Please update the ticket if you would 
prefer other wording or a different location.

Original comment by mgarrish on 20 Sep 2013 at 1:49

  • Changed state: FinalReview

Original comment by ga...@google.com on 24 Sep 2013 at 8:58

  • Changed state: Fixed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment