non linear book structures and spine

3 posts / 0 new
Last post

I observed that several viewer/user-agents/reading systems integrate content documents indicated as non-linear content anyway as linear content within the normal reading order of the spine or at its end, with the result, that the audience gets to these documents by just following the mechanism going from one document to the next in the spine, getting effectively again a linear approach for the content.

This is very confusing/frustrating for non linear works like text adventures.
The best an author of such work can do is currently to add hundreds of empty content documents to the spine between each pair of non linear content documents to ensure, that
it becomes useless to make use of the mechanism of the reading system to follow some
wrong reading order.

I think, both is not very meaningful and the approach with hundreds of empty content documents just to obfuscate the spine reading order mechanism of reading systems mainly blows up the
size of the OPF-documents within the Megabyte range for larger works.

My suggestion is therefore to skip the requirement to note non linear content documents within the spine, to avoid, that reading systems can simply obfuscate the intents of authors by ignoring
linear="no" in the spine.
Another approach would be to add something like a non-spine element for non linear content.
linear="no" seems to have failed due to stupid behaviour of several reading systems.

If there is more than one possible progress from one content document to the next, there is not just one spine, the spine can fork into alternative stories in the simplest case, would be fine,
if it would be possible to indicate such a simple fork within the spine.
For more complex non-linear structures obviously there is typically only the beginning of the
work within a linear order, for everything else one needs the navigation document or linking in each content document to get the reading order intended by the author together with the audience currently reading the work.
If a non-linear work has already more than one starting point however, there is not even a linear starting structure, but here it would be simple to work around this issue with one pseudo-start
forking into the different starting points.

Such forks can be quite useful as well for books in more than one language like manuals as well, not just for belletristic non linear works like text adventures.
Therefore currently EPUB currently does not really cover such use cases due to this spine restriction.

Because EPUB is about digital renditions of a work, not about printed presentations, there is no need to press everything in the limited capabilities and traditions of printed books.

I doubt that this issue will be revisited any time soon. EPUB 3.0 removed the requirement for non-linear content to be listed in the spine, but during 3.0.1 a number of parties objected to the looseness.

The counter-argument is that by not having all the documents in the spine, it removes the ability for someone to easily access all of the content of their publication if they so choose. A user may want to access all the secondary content separately from where it is referenced in the spine if reading in the spine has accessibility issues, for example. It also causes problems for CFI referencing to not have all the documents listed (e.g., multiple paths to the same document through different spine items making things like annotating error prone). I don't remember all the arguments that were made anymore, but I'm sure there were more.

The issue ultimately doesn't boil down to which side the specification takes, though, but how RSes handle the spine. Publishers expect non-linear content not to be shown by default, so you're not alone in that respect, and many voiced their displeasure with the RSes that ignore linearity. But, again, user preference also has to be taken into consideration so it's not enforceable for all reading systems all the time.

What we did do to add some balance was to make it a recommendation that the reading system provide the user control over whether non-linear content appears. It's not going to make every developer do the right thing, but it allowed both sides to move forward on the issue.

Well, if authors/publishers are effectively forced to add hundreds of empty content files between each pair of non-linear content document or linear content document, I cannot see, how this helps to get better accessibility. Such blowing up obfuscation does not make things easier for reading systems with small memory or low computing power.
And because it is not trivial to sort out such empty files (can be filled automatically with ~kilobyte random) there is no chance for reading systems to take into account some user preference to have always a linear approach to a work - those users simply need not to read such non linear works, if they do not like it ;o)
Even if all documents of a completely non-linear work are mentioned in the spine, ordered in alphabetical order of the chapter name or the last characters of the content - how does a linear access to this helps any user?
If it is not linear by design, it is meaningless to force authors to provide some arbitrary linear order - the result will be always nonsense, whatever they will do to work with such a restriction not fitting to their work.

To resume - the current restriction does not really solve a problem, because for authors it is relatively easy to obfuscate linear access with nonsense documents or a nonsense order in the spine.
The only consequence is, that if it really matters, the OPF-document can get quite huge due to the workaround of authors.
One may write, that all documents in the spine are required only for linear works.
For non-linear parts the author is responsible.
If the user really wants to see it all at once in some arbitrary alphabetical order, it is possible to unzip the archive anyway.
And even in this case it is easer to access the content without hundreds or thousands of files randomly filled with nonsense to cover documents with relevant content just to frustrate the required linear access.

Secondary menu