Table of Contents, nesting and playorder.

[Tomkun]

Hello there,

First post and I'm afraid it's a beg for help. I am having issues with the TOC editor in Calibre and would like to know where the fault lies; with me, with calibre or with my reader.

First, some background information. I am using Calibre version 0.9.30 on Windows Vista (both 64 bit versions). My reader is an Acer Iconia A500 running FBReader.

Now the problem. I am trying to create a nested table of contents, or rather tweak a nested table of contents. When I first convert the HTML to ePub, the TOC works fine in the reader, nesting and all. It just requires a quick tidy up.

However, when I use calibre's TOC editor, it seems that the playorder is getting messed up, causing it to display strangely in FBreader.

For example, this is how it is straight after conversion and it works:

BOOK 1 (playorder="1")
---->Chapter 1 (playorder="2")
---->Chapter 2 (playorder="3")
---->Chapter 3 (playorder="4")
BOOK 2 (playorder="5")
---->Chapter 1 (playorder="6")
---->Chapter 2 (playorder="7")
---->Chapter 3 (playorder="8")

Here is how it is after conversion and it doesn't:

BOOK 1 (playorder="1")
---->Chapter 1 (playorder="2")
---->Chapter 2 (playorder="3")
---->Chapter 3 (playorder="4")
BOOK 2 (playorder="2")
---->Chapter 1 (playorder="5")
---->Chapter 2 (playorder="6")
---->Chapter 3 (playorder="7")

Now this is just an example based on me examining the TOC files myself. In FBReader at least this fails. Book 1, chapter 1 is missing and all the rest are under book 2. I can fix it by manually changing the playorder myself.

Before I start filing bug reports I would like to know:

Is this a bug in Calibre?
Is this a bug in FBreader?

Thanks, and sorry for such a long first post!

[kovidgoyal]

playorder in the toc is meaningless, fbreader should not be using it for anything. In an epub file reading order is determined by the <spine> in the opf, not the toc.

However, in the interests of interoperability I will be happy to fix the toc editor to generate depth first play orders, if you can provide me with a an epub and a set of steps to reproduce the messed up play orders.

[Tomkun]

Thanks for the swift and helpful reply.

I am attaching two small and simple epub files which demonstrate the behaviour.
The first has only been converted from HTML to ePub. Nothing else has been done.

The second has been converted from the same HTML file, but has also had the TOC editor opened and closed (no editing was done).

The first works as expected in FBReader, the second doesn't. If you want to see for yourself, simply open the TOC reader and close it again on the first ePub file. You don't even need to edit anything, it seems to rewrite the TOC anyway.

Once again, thank you very much for your help.

[kovidgoyal]

http://bazaar.launchpad.net/~kovid/c...revision/15015

[Tomkun]

Thanks so much for fast fix; I'm looking forward to testing it on Friday!

[Tomkun]

Hi,
Thanks again for doing this, I've tested it today and it now works perfectly. However in testing I noticed that there is another little issue...

When I convert from HTML to ePub, if the original filename has spaces in it, then so do the parts inside the ePub file. This causes some ebooks to fail in CoolReader on Android because it cannot read the filenames correctly.

Is there an option somewhere to automatically remove spaces from filenames, or would it be possible to add?

The problem can be avoided by making sure that your source filename doesn't contain spaces.

[kovidgoyal]

No, there is no such option and I have no interest in adding one. I have enough work on my plate without jumping through hoops to accommodate ridiculous reader bugs like the inability to handle spaces in file names.

[Tomkun]

Thanks anyway, I didn't mean to sound demanding. I certainly didn't expect you to jump through hoops.

I didn't realise it was a bug in the readers though, because when I checked with epubcheck the spaces caused the book to fail validation.

Anyway, like I say it can easily be avoided by removing spaces from the source files.

[kovidgoyal]

epubcheck *warns* (as opposed to errors) about spaces in filenames, precisely because of broken epub readers. However, having spaces is filenames is perfectly valid as per the epub spec.

A warning from epubcheck does not imply an epub fails validation.

[Tomkun]

I understand. Thank you for clearing that up for me.