2.3.2: body Element
It is assumed, in formatting, that the default rendering for body is consistent with the CSS property page-break-before having been set to right (which behaves like always on one-page Reading Systems), but maybe overridden by an appropriate style sheet declaration.
The
spine
represents an ordered subset of the Publication Resources listed in themanifest
, with content items not being referenced being ancillary to those that do.Reading Systems must provide a means of rendering a Publication in the order defined by the
spine
, which includes: 1) recognizing the first primary (linear='yes'
)item
in thespine
as the beginning of the main reading order of the Publication; and, 2) rendering successive primary items in the order given in thespine
.
Thank you guys, my original wording wasn’t clear enough, sorry about that, and thank you for guessing the right one. The book in question has 647 pages without forced page breaks at all to keep the fast reading rhythm, even at the chapter boundaries.
I hope us to discuss on the following points when we discuss on #250:
1. The EPUB 2.0.1 language defines page-break-before:right. Should this be right for both LTR and RTL books, or should this be left for RTL books?
2. In terms of the recommendation for authors if s/he wants no forced page breaks at all, "page-break-before:avoid" on body as Garth suggested is a possible good one from spec perspective, but I’d like more discussions here including opinions from implementations. Concatenating two XHTMLs into a rendering engine might not be technically easy. Also it might not be interoperable if done differently such since how much margins we expect between two body tags are not clearly defined in CSS. I wish the spec be both good, implementable, and interoperable.
As far as I observed Kindle behavior by turning pages very fast, I can see it loads incrementally. Not clear if spines were split beforehand, or it loads long spines incrementally. But I’d like the feature implementable with the similar amount of efforts as the competitors.
Anyway, thanks for the clarifications, Garth, Matt, and Bill. This definitely help us all.
/koji
Hachette, thank you for the valuable feedback. I agree with you, we should try to keep things as simple as possible, and “use long spine if you don’t want forced page breaks” is one of the possible solutions.
The problem right now is that, we don’t have a clear message to tell to authors for how to create a long document without forced page breaks. 300k might be ok, but 900k or 1.6MB in my case usually give bad experience. Googling “epub slow” gives some real examples.
If you ask vendors for better experience, it’s likely that they’ll recommend you to split spines, saying it is known to be the best practice, but you can’t avoid page breaks if you go that route, and you’re stuck.
I would like to have a single message where authors and vendors agree with. It can be either yours or Bill’s.
/koji
First of all, if you have anything that should be addressed in text and vertical typography, please post to www-...@w3.org, or post here and I’ll forward them to CSS WG. I’m not hearing much requests in this area, if you have any, I’d appreciate to know.
Second. I agree, we should try our best not to increase complexity, and I’d like the solution as simple as possible too. But since we want EPUB to be single, global, open standard, two members saying 300KB is enough does not invalidate wish for 1.6MB from other members. I agree it needs to be properly prioritized depends on how many members wish though.
Third. HTML, from W3C perspective, at least as of now, is not a page display engine unfortunately. Technically speaking, it’s CSS WG’s responsibility, not HTML WG’s, and CSS WG often hears wishes in this area, but there’re no volunteers to work on paged media today, so there’s very little progress. Actually, since most browser users have little interests in improving printing a.k.a, paged media, CSS WG appreciates volunteers from e-book world.
Last, to Bill’s comment. Apart from the wish, I agree that clarifying the basic execution model of an EPUB RS helps us to be more interoperable and is good thing to work on. I agree that discussing and clarifying spine boundary behavior is also great. Knowing these two are separate topic from the wish, I appreciate the wish can also be discussed when we start EPUGB 3.(0).1.
/koji
Third : you are right HTML itself is not “a page rendering engine”, but a web browser is, is it not ? Don’t we call an HTML file a “web page”? And is it not consumed as such by the web browser?
Luc
De :
epub-work...@googlegroups.com
[mailto:epub-work...@googlegroups.com] De la part de Ishii, Koji a
| Koji | EBJB
Envoyé : mardi 8 janvier 2013 15:39
À : epub-work...@googlegroups.com
Objet : RE: Long spine issue
Third : you are right HTML itself is not “a page rendering engine”, but a web browser is, is it not ? Don’t we call an HTML file a “web page”? And is it not consumed as such by the web browser?
Maybe I understand “page” incorrect, sorry about that. HTML does not define layout at all, CSS does. CSS defines two modes; scrollable media and paged media. Paged media is used only on printing in browsers, so most browser vendors do not spend much efforts on it, but e-books relies on it heavily, so issues that happens only on paged media are hard to resolve.
That’s what I meant “page,” and looks like I misunderstood. Sorry about this.