Minimal and ideal EPUB3 testcase?

[ibu]

@Doitsu
Sorry, I'm responsible for the missunderstanding. I remembered, what you wrote and that I have to change to "kepub.epub". And that I have to check all Kobo specific needs for epub3.
My sentence in #29 was just a report, not a hidden question how to solve it. I wanted to separate the minimalization from the changes which are Kobo specific. But it was my fault, that I didn't communicate it clearly.

With the extension "kepub.epub" the cover and the TOC are shown perfectly in the Kobo.

Edit:
When I remove the nav entry from spine the epub3 validates but it has an interesting effect in Kobo:
The TOC just works fine. But the cover will not be shown.
But please just regard that as note. I will discuss all Kobo specific issues in the Kobo forum.

[DaleDe]

Originally Posted by ibu

Thanks for the hint about the cover image.
I added the attribute "properties".

And I separated the the nav.

The validated attachement contains the changes. When we finishe this thread, I will edit the first posting and will attache the final file so it is easier for readers to find the latest version.

The cover is not visible in the Kobo. Nor it is the TOC.
But I haven't started with the work to make the minimal epub3 compatible to KOBO. That may be the reason.

About the validator:
May be it would be useful, when it warns, if a nav does not exist as a separated file?

It is not required to be in a separate file. ADE found it in the navigation screen and displayed it fine and also in the book. That is ok if that is what you want. But to match the paper book it should be near the front, not at the end.

Note that the replacement didn't have any pictures in it.

[KevinH]

The epub3 spec is unclear. All throughout the spec they talk as if the navdoc is a required separate xhtml file. No where I could find in the epub 3.01 spec did it say that it could be mixed into a more general xhtml file. That said, I could not find a clear line that the navdoc MUST be the only thing in that file either.

Given the navdoc is machine parsed by reading systems (but still usable for human viewing) I think it would be safest in its own doc with the nav property set in the manifest.

[Doitsu]

Originally Posted by KevinH

The epub3 spec is unclear. All throughout the spec they talk as if the navdoc is a required separate xhtml file.

IMHO, it's safe to assume that this is the case, because official and semi-official IDPF epub3 sample files always contain separate NAV docs.

For example:

a) The four quasi-normative sample files linked to in the EPUB 3 Accessibility Guidelines all have separate NAV docs.

b) All EPUB 3 Test Suite files have separate NAV docs.

[ibu]

Thanks for the discussion about separating/not separating the nav.

Your arguments pro separating are convincing.

One point please: How do you interpret the specs regarding the spine and the nav please?

Must the nav.xhtml be an entry in the spine or not?

I regard the case, where the user wants to see the TOC only, when he uses the "show TOC" function in his device. He doesn't want to see it as part of the normal content of the book.

[Doitsu]

Originally Posted by ibu

Must the nav.xhtml be an entry in the spine or not?

AFAIK, the NAV doc needs to be referenced in the spine.

Originally Posted by ibu

I regard the case, where the user wants to see the TOC only, when he uses the "show TOC" function in his device. He doesn't want to see it as part of the normal content of the book.

You disable access to spine items via the page forward/back buttons with the linear="no" attribute. (Most epub3 apps will honor this attribute, but epub2 apps will usually ignore it.)

    <itemref idref="nav" linear="no"/>

[ibu]

What a pity, that the specs are in some areas not clear. Well, I will insert the nav entry in spine, because otherwise Kobo will be "confused" (it does not show the cover, nor does the TOC work as I mentioned before).

I tried linear="no" - thanks for the hint, Doitsu.

In Kobo it has no effect. Still the content appears via page forward/back buttons.
And, as a note: the content of nav.xhtml will not be displayed like the content of content.xhml in Kobo. At nav.xhtml you find page margins. at content.xhtml you didn't.

There's a lot work for me to do: I will change to the Kobo forum, to get help about all these "effects" of the Kobo software. Hopefully there's a way to realize the CSS rule page-break: before for headings in a Kobo. If not, my clean and simple concept of "one content file does it all" could not be used.

As promised, I attached the complete minimal epub3 file in my first posting, to make it easy for readers to find the latest version.

[jhowell]

Originally Posted by Doitsu

AFAIK, the NAV doc needs to be referenced in the spine.

I disagree. The EPUB 3 specification indicates that the NAV is not required to be in the spine. From EPUB Publications 3.0.1, Section 3.4.12 The spine Element:

All EPUB Content Documents that are linked to from EPUB Content Documents in the spine must themselves be listed in the spine. Linked documents include documents referenced from the href attribute of a and area elements and scripted links (e.g., using DOM Events and/or form elements). All EPUB Content Documents linked to from the EPUB Navigation Document must be listed in the spine, as well, regardless of whether the Navigation Document has been included in the spine. The requirement to list linked documents applies recursively (i.e., all Content Documents linked to from linked Content Documents also have to be listed, and so on.).

I have seen commercial epubs with the NAV file left out of the spine and they pass epubcheck with no errors or warnings.

[Doitsu]

Originally Posted by jhowell

I disagree. The EPUB 3 specification indicates that the NAV is not required to be in the spine.

I stand corrected.

[DaleDe]

Using the latest document on ADE I find that there are no images. The page numbers always refer to 4 of 4 no matter where you go. The first version is still the best version IMHO.

Dale

[ibu]

@Dale
I'm not sure, what is a best practice for a minimal testcase.

At the moment I tend to really use only valid code, conform to the specs.
Only than one could see, which epub3 software does not show every part (cover, TOC) correctly or has serious bugs.

ADE and Kobos Kepub software both fail with the minimal testcase.

May be I should link a second epub file which contains "extra code to satisfy buggy rendering software".

Thanks for your feedback. Good to know that not only Kobo fails, when the nav is not mentioned in the spine.

What do you think is a good practice for a minimal testcase?

[DaleDe]

I liked the depth of the first case. It intended to have a cover and an image inside. It had a toc and pages of text with various sizes and semantics. It covered the ground pretty well for what a eBook might look like.

Dale

[ibu]

Thanks for your feedback, Dale.

The only difference in the actual version (linked in the first posting) and the other older versions is the entry for the nav in the spine in the opf file.
And I removed the picture of the author inside the text, because I thought, that a picture in a book is optional. The most literature I read contains no pictures.

So I thought it is OK for book testcase which wants to "minimal".

The complete text/semantics are the same.
And the cover, of course, is integrated.

Some software may not display the cover or the TOC, because of bugs.

I will soon attache an extra version of the epub3 testcase, which focusses on Kobo.

Than I have to find out, if there's a way to let the Kobo software display more than one level in a TOC.

Edit:
Good news!
The latest FW update of Kobo eliminated the bug with "not showing the cover" in my testcase.
Now it is shown. Very nice.
Attention! If you like to test epub3 files on a Kobo, you have to change the extension from ".epub" to ".kepub.epub".