Re: TS 209 (+ rendition:flow questions)

[Ric Wright]

+Markus, Garth

Didn’t see any response to this.  I am curious as to what the answer is.  In addition, I am now looking at crafting some tests for the rendition:flow properties and there is a related question there (to me, at least).

If a book says that its layout is pre-paginated, but the spine-item specifies that the item is scrolled-doc (for example) I assume that we should override the fixed-layout size, including the meta-viewport or view box element (if any) in the HTML (or SVG).  This may be a bit interesting to implement.  And it better have been designed to be that way or the result is going to look like the dog’s breakfast (based on long experience with trying to reflow PDFs).

In reverse, if a book says it is reflowable, but a spine item says that the item is paginated, how do we determine the size if the item doesn’t contain a meta tag with the size or viewport?  Would that be an error?

Thanks

Ric

From: Ric Wright <rkwr...@geofx.com>
Reply-To: <epub-testsu...@googlegroups.com>
Date: Tuesday, April 1, 2014 at 9:15 AM
To: "epub-testsu...@googlegroups.com" <epub-testsu...@googlegroups.com>
Subject: TS 209

Forgive me if this has been previously discussed (couldn’t find any reference).  Test Suite doc 209 declares in the OPF that the content doc is reflowable:

<meta property="rendition:layout">reflowable</meta>

But each of the XHTML files declare that the layout is static:

<meta name="viewport" content="width=576, height=1024"/>

Is this an error?  Or is the RS supposed to (somehow) override the <meta> tag in the XHTML document?

Page 4 explicitly overrides the OPF tag to specify the page is pre-paginated.  So should pages 3, 5 and 6 be reflowable?

Thanks

Ric

--
You received this message because you are subscribed to the Google Groups "epub-testsuite-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to epub-testsuite-di...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ori Idan]

On Wed, Apr 2, 2014 at 10:00 PM, Ric Wright <rkwr...@geofx.com> wrote:

+Markus, Garth

Didn’t see any response to this.  I am curious as to what the answer is.  In addition, I am now looking at crafting some tests for the rendition:flow properties and there is a related question there (to me, at least).

If a book says that its layout is pre-paginated, but the spine-item specifies that the item is scrolled-doc (for example) I assume that we should override the fixed-layout size, including the meta-viewport or view box element (if any) in the HTML (or SVG).  This may be a bit interesting to implement.  And it better have been designed to be that way or the result is going to look like the dog’s breakfast (based on long experience with trying to reflow PDFs).

I think you are right, we should assume scrolled will override fixed-layout, I think the standard doesn't say anything about it. 

In reverse, if a book says it is reflowable, but a spine item says that the item is paginated, how do we determine the size if the item doesn’t contain a meta tag with the size or viewport?  Would that be an error?

That is currently not an error in epubcheck as much as I know. But you are right, it should be an error since the RS must have a method to determine the size of the page.

 

Thanks

Ric

-- 

Ori Idan CEO Helicon Books

http://www.heliconbooks.com

[Ric Wright]

+Garth

Thanks Ori.  It is a little ambivalent in the spec (IMO) but a “reasonable” person would interpret it as you have.  

Agreed about EPUBCheck, but as Matt has pointed out to me (quite correctly), EPUBCheck doesn’t claim to be a EPUB 3.0.1 validator.  :-)

Ric

[Matt Garrish]

(+Romain who is best to answer when epubcheck will handle the new 3.0.1 requirements, which obviously has to be after the spec becomes a recommendation.)

 

To scrolled-doc, the spec was intentionally silent because, as I recall, we didn’t want to require a specific rendering mechanism, which could be problematic depending on the capabilities of any given device.

 

A scrolled-doc was only intended to be the equivalent of top-bottom reading with left-right progression (swapping those directions per your region). Magazines are one area I remember being brought up, where this would allow easy movement from article to article by typical left/right swiping, while allowing scrolled reading of the pages in each article.

 

There were questions at the time about memory/performance impact of such an interface, leading to what a “scroll” means being open. It could mean that all the pages are loaded at once, creating a single scrolled document from the pages (where width is the widest document and height is the concatenation of all heights), or it could simply mean that bidirectional navigation is enabled, and the “scroll” is only movement from one content doc to the next from top to bottom (so each page’s viewport would be respected).

 

Those are my recollections, at least, but I’ll defer to Garth and Markus on whether my understanding of those discussions matches theirs.

 

Matt

[Matt Garrish]

Hm, I should reread the specs before responding... I just wrote a defense of scrolled-continuous, didn’t I? :)

 

Scrolled-doc does not apply to pre-paginated documents, per its definition:

 

This property must not be specified on an itemref that also specifies the rendition:flow-auto,rendition:flow-scrolled-continuous or rendition:flow-paginated properties.

 

Matt

[Ric Wright]

Matt,

Thanks for the reply.  

Re the general case (simply scrolling up/down), what we have implemented is lazy-update, in that we never load more than 3 pages at a time (the one above the one below and the current page).  Others are swapped in as needed and the no-longer-needed discarded.  We could expand the buffer and keep N above, N down, etc. in case the viewer needs to scroll up and down quickly.  But I suspect we won’t do that.

We did this for two reasons:

• Memory/performance. Obviously, you don’t want to load all of War and Peace at once…
• Security.  If the entire document is loaded (or even spine-item by spine-item) you have made it considerably easier for users to copy the document and do with it what they wish

Re magazines, yes, this is the approach that Adobe DPS took with the articles a vertical “scrollable” “page" and the articles (corresponding to spine items) to the left and right (virtually).

Ric

[Matt Garrish]

Reviewing the properties, the top/bottom and left/right navigation is somewhat flaky right now, at least for FXL. I don’t think you can implement what I described below, since there’s no way to indicate where one continuous scroll ends and the next begins.

 

For reflowable, you can make each document a scrolled-doc, but for pre-paginated pages you can’t indicate where one set of pages ends and the next one begins, without inserting a non-scrolled document between them. All you can do is make the entire FXL publication scrolled-continuous.

[Ori Idan]

On Wed, Apr 2, 2014 at 11:58 PM, Ric Wright <rkwr...@geofx.com> wrote:

+Garth

Thanks Ori.  It is a little ambivalent in the spec (IMO) but a “reasonable” person would interpret it as you have.  

Agreed about EPUBCheck, but as Matt has pointed out to me (quite correctly), EPUBCheck doesn’t claim to be a EPUB 3.0.1 validator.  :-)

EPUBCheck is not yet 3.0.1 compliant, however fixed layout spine items in reflowable document exist in 3.0 (although I haven't seen any RS that support it).

[Daniel Weck]

On Thu, Apr 3, 2014 at 5:12 AM, Ori Idan <o...@heliconbooks.com> wrote:
> EPUBCheck is not yet 3.0.1 compliant, however fixed layout spine items in
> reflowable document exist in 3.0 (although I haven't seen any RS that
> support it).

Actually, Readium handles mixed fixed-layout (aka pre-paginated) +
reflowable spine items...but the functionality is not available in the
publicly-available Chrome extension just yet :)

Daniel

[Matt Garrish]

Right, Apple, Google, B&N, Readium and others have supported FXL properties,
to varying degrees, since publication of the original FXL informational
document[1] (and some in proprietary ways before, as you can find in the
mappings appendix).

As FXL was only an informational document prior to 3.0.1, that's why the
properties are not currently validated.

The modular nature of the next epubcheck I’m hoping will address plug-in
validation for these kinds of peripheral documents going forward as they
build support for becoming part of the core. It should also introduce
validation for the properties based on their 3.0.1 definitions, reducing the
errors.

[1] http://www.idpf.org/epub/fxl/

Matt

-----Original Message-----
From: Daniel Weck
Sent: Thursday, April 03, 2014 7:27 AM
To: epub-testsu...@googlegroups.com
Cc: Garth Conboy

Subject: Re: TS 209 (+ rendition:flow questions)

[Daniel Weck]

(adding Boris who implemented rendition-flow)

Readium currently uses a fixed width (that of the visible viewport)
for all content documents in the top-to-bottom sequence of spine
items, regardless of whether each individual spine item is a
reflowable or pre-paginated document. By virtue of a pre-paginated
content document's meta viewport dimensions (aspect ratio), fixing the
width results in a height that may or may not fit within the visible
viewport height. In scrolled-doc mode, this means adding a vertical
scroll bar. In scroll-continuous mode, each individual spine item
occupies as much height as required.
Personally I like the fixed width, it makes the reading experience a
lot easier because the scroll direction is on one axis only. I
understand the rationale for allowing a "landscape" spine item to
stretch horizontally greater than its sibling "portrait" documents,
but I'm not so sure about usability (2-axis scrolling pane?).

Daniel

[Garth Conboy]

And, FWIW, a comment I made yesterday (before I joined the group — hopefully this incarnation won’t bounce):

My 2-cents...

For an item to be Fixed Layout, it must declared that way in the OPF -- either globally or with a spine-item override (if the default is flowing).  Any such Fixed Layout spine item MUST contain a viewport (for dimensions) or be SVG (with viewport info) [this is from the spec].

In the above example, assuming the spine item with the <meta> "viewport" , isn't declared (one way or another) as Fixed, the viewport information is irrelevant and should be ignored.

Best,

   Garth