Colophon should not be set to linear=no in spine even if it precedes the title page

[AndersEkl]

Originally written by @martinpub

Although perhaps not very common, colophons might be located before the title page. Currently, the guidelines state that "linear="no" should generally be applied to all content documents representing content that precedes the title page, e.g. cover, half-title page, etc.".

It might be a good idea to clarify that pre-title page colophons should not have linear=no in the spine?

[jonaslil]

I agree with this. I don't think any text content in the beginning of the book should be set to linear=no. Is there a reason why we don't want the cover to be linear content, and want the reader to always land on the title page? I think some readers might appreciate being able to view the cover in full page size.

[josteinaj]

The cover is displayed on bookshelves, screen locks etcetera, so you'll usually have seen it before you open the book.

If you want to access it, you can also reach it through the reading system toc (i.e. the navigation document).

Having both the cover and title page as part of the normal reading order is redundant in my opinion.

[oscarlcarlsson]

As it looks in our current markup, the back cover text is in the same file as the cover. Could this be something that we want to be included in the linear reading order?

[jonaslil]

I think so. Non-linear spine items are handled inconsistently in different reading systems. For me, they create a confusing reading reading experience, where you can't always page forward (or backwards) to other content in the way the placement of the items in the toc would suggest. I think as a rule, all text content should be in the linear reading order, unless it is clearly supplementary to some other linear content.

There doesn't seem to be any instruction in the current guidelines about including the cover text.

[oscarlcarlsson]

interesting point about this not being included in the current guidelines. is this just a remnant of the 2015-1 guidelines that they still follow in the 2020-1 guidelines?

[oscarlcarlsson]

if we don't want any linear="no" items in the spine: could we use the titlepage for both titlepage and cover/back cover and keep it as linear? would it be a problem to include the cover-image after title and author?

[jonaslil]

I think having the front cover image after the titlepage might be a bit confusing. Readers probably expect the cover to come first in the content (if it is included in there) and in the toc. It matches the order in print books and most publisher epubs.

I noticed that in the Calibre ebook viewer, I can't get access to any additional content in the file that contains the front cover. (Thorium does not have this problem.) Which makes me think that it is safest not to have anything else in this file, and have title page and back cover text in their own files.

Now, testing two of our books on the Ipad - with Apple Books and Aldiko next - I can't access the nonlinear content in the beginning of the book at all. Not through the nav toc, not by paging back from the first linear file.

[josteinaj]

Do we need the cover image as part of the content? It should be marked up as a cover image in the OPF metadata so that it is shown on bookshelves.

A use case might be if you want to view it in full size and zoom in etc, but that's not something you need in most cases. If we need that possibility, then maybe it would be sufficient to have the cover content document at the end of the book? Possibly along with other cover content?

[oscarlcarlsson]

@jonaslil titlepage was a confusing thing for me to call it. what i was thinking was that it could be a good idea to inclide the title and the autor as text in connection with the cover at the start of the book.

The way our Daisy-files are structured at the moment is: Title + Author MTM information Cover Back cover [The rest of the book]

[oscarlcarlsson]

@josteinaj if we include the back cover text in the book, don't you want it to be included before the rest of the content?

[josteinaj]

Well, we've previously talked about reducing the amount of content at the start of the book so that you get to the actual content faster.

What do you think @eliseaas? Check with Eivind?

[eliseaas]

We generally want all superfluous content to be added to the back of the book as it can often take a lot of manoeuvring for the reader to get to the actual content they want to read. (I have checked with Eivind, who agrees.)

[oscarlcarlsson]

@eliseaas do you add linear="no" to more frontmatter-content than the information preceding titlepage, then (e.g. dedication)

[eliseaas]

@eliseaas do you add linear="no" to more frontmatter-content than the information preceding titlepage, then (e.g. dedication)

Not currently, as far as I'm aware. The 2015-guidelines only specify that the cover should be linear="no".

[oscarlcarlsson]

My suggestion is that we go for the general rule that only the cover is set to linear="no", since different reading systems handle linear="no" differently. I believe that different agencies will handle this differently. But keeping all of the content easily accessible no matter the reading system is probably a good idea.

For validation-rules we wouldn't have to change anything here.

[jonaslil]

I agree, with the addition that it would be best to have the front cover in a separate xhtml document and only this is set to linear="no".

[martinpub]

I agree, with the addition that it would be best to have the front cover in a separate xhtml document and only this is set to linear="no".

I agree too, with this addition. I think this issue should be reopened until we have made the necessary changes to the instructions on the cover content file: https://github.com/nlbdev/nordic-accessible-epub-guidelines/blob/29e76e2e0a976e33d4a8b1b3cb5c2a3d478b09be/guidelines/guidelines.md?plain=1#L593-L604

[oscarlcarlsson]

Should we keep the cover-image as its own file, which we keep as linear="no" and keep the back-cover and flaps as a frontmatter?

[oscarlcarlsson]

added an update to #63 that should close this as well.