<itemref idref="nav" linear="no" /> misplaces TOC in ePub

[ousia]

I’m not sure this is a bug, but I think it may be one:

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

linear=no misplaces the table of contents in the ebook-viewer from calibre.

But besides that, that attribute seems to be intended to remove the file from the reading order and making it accessible only by a link.

AFAIK, there is no way to access to the TOC other than the reading order in ePub files generating with pandoc.

Would it be possible to remove linear=no from <itemref idref="nav" linear="no" />?

Many thanks for your help.

[jgm]

If you specify --toc on the command line, you will get linear="yes",
which appears to be what you want. So I don't see a bug here.

+++ Pablo Rodríguez [Aug 31 14 12:57 ]:

I’m not sure this is a bug, but I think it may be one:

linear=no misplaces the table of contents in the ebook-viewer from
calibre.

But besides that, that attribute seems to be intended to remove the
file from the reading order and making it accessible only by a link.

AFAIK, there is no way to access to the TOC other than the reading
order in ePub files generating with pandoc.

Would it be possible to remove linear=no from ?

Many thanks for your help.

—
Reply to this email directly or [1]view it on GitHub.

References

1. <itemref idref="nav" linear="no" /> misplaces TOC in ePub #1593

[ousia]

Besides from specifying --toc in the command line, there is a bug in the misplaced TOC.

The bug is what you get by using linear=no. The specification allows the reading system to change location of that item.

This is why different software display the TOC in different positions with the same ePub file.

The best way to solve this would be to remove (unless --toc is specified) <itemref idref="nav" linear="no" /> in the <spine>.

BTW, from the spec:

(linear="yes", which is the default when linear is not present)

I think it might be safe to remove these attributes.

[jgm]

+++ Pablo Rodríguez [Sep 01 14 07:55 ]:

The best way to solve this would be to remove (unless --toc is
specified) in the .

The toc is required in EPUB3. I had thought that it would need to
be in the spine as well, but if not, then this would be a good
solution.

I just tried removing it, and it seemed to validate.

[ousia]

I just tried removing it, and it seemed to validate.

According to the specification, it is valid ePub 2, since the document is included in <guide>.

[jgm]

+++ Pablo Rodríguez [Sep 01 14 08:25 ]:

I just tried removing it, and it seemed to validate.

According to the specification, it is valid ePub 2, since the document
is included in .

I was more worried about epub 3, which is the one that requires
the nav.

[ousia]

Well, I’m afraid I don’t find the passage in the spec for ePub 3 in which explains whether nav.xhtml can be removed from <spine>.

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.

Well, this is too generic for me. It means that fonts, SVG are auxiliary items.

But an example in the spec shows exactly what we are looking for. The <manifest> example list as first item nav.xhtml. The <spine> corresponding to that <manifest> example reads:

<spine page-progression-direction="ltr">
    <itemref idref="intro"/>
    <itemref idref="c1"/>
    <itemref idref="c1-answerkey" linear="no"/>
    <itemref idref="c2"/>
    <itemref idref="c2-answerkey" linear="no"/>
    <itemref idref="c3"/>
    <itemref idref="c3-answerkey" linear="no"/>
    <itemref idref="notes" linear="no"/>
</spine>

nav.xhtml is removed, so I think it is safe to assume that removing this item, when referenced in <landmarks> (see next paragraph), is a safe practice in ePub 3.

It is important to notice that in ePub 3, <guide> seems to have been deprecated in favour of <landmarks> (see spec).

BTW, it would be fine to remove linear="no" from <itemref idref="cover" linear="no" />, since disabling linearity only introduces uncertainty in display order. The reading system sets the reading order. I guess that this is something that should be avoided with a cover. And the cover is not an auxiliary item. This is valid for both ePub 2 & 3.

I hope it helps now.