Based on the discussion, the two areas of greatest
From the EPUB3 spec:
The spine element defines the default reading order of the EPUB Publication content by defining an ordered list of manifest item references.
The spine represents an ordered subset of the Publication Resources listed in the manifest, 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 the spine as the beginning of the main reading order of the Publication; and, 2) rendering successive primary items in the order given in the spine.
So a component that isn't in the spine is "ancillary" to the main content. This is interesting, because no such burden is placed on nav. In fact, for some FXL children's books, our nav file consists of a single entry, labelled "begin reading." That label reminds us there is text associated with each entry in a nav element, the title of the thing you're pointing to. So we have one thing (spine) that is required to point to all the "primary" components of the document, but has no obligation to name those components. And we have a different thing (nav) that is required to name any component it points to, but is (mostly) optional.
EPUB Zero proposes that index.html contain at least one nav element, which would identify the primary reading order of a document based on the content documents (not necessarily html) referenced.
So in some sense we're requiring the main navigation document to identify and label every component of the primary reading order, which is a greater constraint than in EPUB3. Could this raise the baseline for accessibility?
If we do this, the primary navigation document could not refer to files that are not in the linear reading order. Is this too high a price to pay? Is there a class of documents that aren't important enough to be in the main flow, but too important to omit from the primary nav file? I believe I could happily live with such a restriction, but I wonder what others think. [keep in mind there would be no restriction on linking to 'out-of-spine' content].
If we separate the functions of navigation and reading order, how would we describe the reading order using only HTML5? If there is a "navigation" nav file, and a "reading order" nav file, how do we distinguish them?
One way to describe the reading order separately using only HTML would be to use link elements in the header of each document, with the next and prev link types.
ReplyDeleteThat would exclude non-HTML content documents, though.
It would allow non-linear orders - going in a circle would probably be unhelpful, but an out-of-spine item that can only be reached by a link could still have previous and next items; not sure if that would be helpful.
If there was a way to specify a link to another ePub it could easily be extended to having the final section of a book contain a pointer to the next one in the series, which would be neat.
So thinking along these lines some more, but not strictly related...
DeleteIf we have a link element in each content document pointing to the index.html, we could get a single html file via http, and from that have links to the rest of the document. So ebooks could live on the web. Mostly not terribly interesting, but it would allow ebooks that are updated more frequently, or have built-in comments, or are just generally getting dynamic info from the server - at the most extreme, an email app or RSS reader implemented as an ebook.
dave, are you serious about moving forward on this?
ReplyDeleteif so, then do your goal some justice, and do it right.
if you really want "epub0", cut things back to this:
1. all .html files are combined into _one._
(i'll pretend for the moment that we're still
using .html files. but just for the moment.
eventually, light-markup will be even better.)
2. anything in the .zip file is part of the book.
(we'll .zip the book to transport it. but initially,
any file in the book's folder is part of the book.)
3. now we have no need for a "nav" or a "spine".
(or, to use other terms, we ditch .ncx and .opf.)
4. we can (should) require a "contents" section,
and i will suggest that it should be mandated as
the second section, after the cover-title section.
this inline table-of-contents would not be strictly
"necessary" for the e-book itself, as it _must_be_
an accurate reflection of the headers in the book.
that is, it serves as belt to the header suspenders,
and is thus, in a real sense, entirely _redundant._
but an explicit inline table-of-contents makes it
easier for our people to work with the e-book file,
and also make it simpler to create a chapter-catalog
for our online library containing millions of e-books,
because we won't have to load in every bit of the files.
5. any content files unaddressed directly by the .html
are understood to be "auxiliary", and will be tacked on
at the end when the book is displayed by an end-user.
i'd suggest they be ordered alphabetically by filename,
but we can also specify that the order will be arbitrary.
(because if the order is important, put it in the .html!)
there, now you have something closer to "zero"...
-bowerbird
bowerbird,
DeleteThat's exactly what I was thinking about these days : this is the epub0! Just one plain HTML file.
As HTML rendering engine are not powerful enough to compose the equivalent of hundreds of paper pages, it gives us at least one reason why it is necessary to chunk the content of a book in several files. Has any actual web page be longer than a short story?
Thank you Dave for this idea!
Luc
bowerbird,
DeleteAgree with [2], [3] and [5]; agree that some sort of navigation/toc is necessary, whatever form that may take. Disagree on [1] but I've talked about that elsewhere.
This is moving forward; I believe there will be an implementation rather soon, much to my surprise. It will be more complicated than you would like; it will likely be more complicated than I would like, too. I suppose I'm too attached to worldly things (like XSL!) to become enlightened :)
luc said:
ReplyDelete> HTML rendering engine are not powerful enough to
> compose the equivalent of hundreds of paper pages
of course they are powerful enough. project gutenberg
has always had its html-books composed of a single file.
the 300k limitation of sony/adobe is simply ludicrous...
-bowerbird
We have a novel with 1.4 million words; a text-only file is 7.7M. But I think the issue is more with textbooks, which may have hundreds of megabytes of text, images, and so on. The books the company I work for publish are but a tiny corner of a much larger world.
DeleteDave,
ReplyDeleteAs you know, I'm strongly in favor of keeping a reading order (the spine) separate from the navigation (navigation document).
I believe that the reading order should be required, and the navigation optional.
In EPUB3, we force the content creator to list in the spine all of the content document that could be displayed, which brings the concept of "linearity" to the table.
Here are my thoughts about it:
- let's drop this constraint, the spine would just be the reading order, you'd still be allowed to link to out-of-spine documents from either navigation or content documents
- if we don't need to list all content documents in the spine, then we can drop the "linear" attribute, it is entirely unnecessary
EPUB3 also limit what can be linked in the spine without any proper fallback (XHTML and SVG). I believe that this should be extended to bitmap images, audio and video too.
Finally if we drop the manifest and agree that the container (zip) is the manifest, then we need to decide if we still need fallbacks and bindings. Are they really necessary ? Do content creators and RS use them ?
Hadrien,
DeleteA reading order could quite naturally be tagged as an ordered list in HTML5, which could be hidden if you don't want it displayed. I'm concerned that in many cases such a list would be very similar to the book's nav file, hence the desire to not duplicate this information. If the reading order is required, and nav is optional, what then? The reading order has become the default navigation document.
Perhaps I'm just looking for examples where this reading order would be substantially different from nav (aside from easy cases like nav having multiple pointers into the same doc).
I do agree on allowing links to documents that are not in the reading order (however expressed).
Having bitmap images in the reading order can be problematic for reading systems, I'm told. I remain agnostic at this point in time :)
From personal experience, we haven't used fallbacks beyond having some boilerplate text inside video and audio elements, but again our content is simpler than most. My hope is that avoiding non-HTML5 constructs will reduce the need for such things.
Fully agree that both should be expressed as a list in HTML5, in the index.html.
DeleteAlso, since the navigation would be optional (unlike the reading order), the reading order could be used as a default TOC if no additional navigation is defined and it is not hidden.
Textbooks are a good example where reading order and navigation can be very different from one another.
Aside from purely accessibility issues, I don't see how bitmap images can be much of an issue.
If we want EPUB Zero to be a good fit for comics too, it should be able to compete with CBZ/CBR both in terms of simplicity and features.
If we can create comics with just bitmap images and an index.html in a zip file, we'd have the right balance: simple enough (no need to embed images in HTML or SVG documents with fixed layout properties) yet more powerful than CBZ/CBR (thanks to metadata and navigation in index.html, including an optional panel by panel navigation).
dave said:
ReplyDelete> We have a novel with 1.4 million words;
> a text-only file is 7.7M.
no big deal; i can handle it. if you doubt me,
change all the lowercase vowels to "x" and
send it to me. i'll send back a working app.
> But I think the issue is more with textbooks,
> which may have hundreds of megabytes
> of text, images, and so on.
although i'm not sure what "and so on" means,
i can confidently say that i can handle that too.
unless you want those "hundreds of megabytes"
of pictures displayed on-screen simultaneously.
but i sincerely doubt you have a screen that big.
> The books the company I work for publish
> are but a tiny corner of a much larger world.
i can vouch that i'm familiar with the range of
books that reside in that "much larger world",
and i am confident that i can handle the bulk.
but i do love a challenge, so if there's something
you think that i cannot deal with, send it to me...
-bowerbird