I managed to trigger a very interesting bug... :)

[patrik]

If I start to read the book (kepub), and page through it all the way to the end, all is fine.

But if I enter the inline toc and choose the first chapter, it goes to the first page of the first chapter, and now show it full page! (no header, no footer, no nothing).

If I page through the chapter it shows every page like that. When the chapter is finished it restarts the book at the cover and all is as usual again.

Interesting....

--

It's a book from amazon -> Calibre & kindle unpack -> sigil (split chapters into files, created toc) -> Calibre -> extended -> Kobo

I have hade som strange "toc not working perfectly" before in other books (with several different firmwares).

EpubCheck screams at me, I suppose I have made some errors along the way, but it's a interesting feature-enabler I think.

[JSWolf]

I think the problem is that you need to make sure epubcheck does not come up with any errors and you should have every file in the NCX ToC. If you didn't do this, then yes, strange things can happen.

Many glitches (not just Kobo) happen with eBooks with errors.

And it's not a bug if the eBook is not well formed.

[geek1011]

Originally Posted by JSWolf

I think the problem is that you need to make sure epubcheck does not come up with any errors and you should have every file in the NCX ToC. If you didn't do this, then yes, strange things can happen.

Many glitches (not just Kobo) happen with eBooks with errors.

And it's not a bug if the eBook is not well formed.

And don't worry about RSC-005 too much, it is just an annoying check which doesn't affect much, and almost every book fails this check.

[JSWolf]

The thing is, you get less problems when your eBooks have no errors. Sme of what are thought of as bugs are not bugs in the firmware, but are in fact problems with the eBook.

[compurandom]

This is a bug I've been fighting with for a while.

If the first html file of a epub (converted to a kepub) is not the title page, it gets rendered as a title page anyway. (I think this is not a problem if there is only one html file in the epub.) I believe this is also a problem if the book has a title page, but it is a jpg instead of an html file, but I haven't done enough testing to know if this is always the case.

The way to solve it is to use the calibre plugins modify epub or polish epub to insert a title page.

[DNSB]

Originally Posted by compurandom

This is a bug I've been fighting with for a while.

If the first html file of a epub (converted to a kepub) is not the title page, it gets rendered as a title page anyway. (I think this is not a problem if there is only one html file in the epub.) I believe this is also a problem if the book has a title page, but it is a jpg instead of an html file, but I haven't done enough testing to know if this is always the case.

The way to solve it is to use the calibre plugins modify epub or polish epub to insert a title page.

If I am going to convert an epub to kepub, I simply make sure that the cover image entry in the content.opf file is correctly formatted. This includes the properties="cover-image" item in the cover image's entry in the <manifest> section of content.opf. See the two lines below for a sample.

epub:
<item id="cover" href="Images/cover.jpg" media-type="image/jpeg"/>

kepub:
<item id="cover" href="Images/cover.jpg" media-type="image/jpeg" properties="cover-image"/>

Since this is a by design behaviour and complies with the epub3 spec, calling it a bug is a bit of drawing the long bow. The EPUB 3.0 documentation contains the following:

› cover-image
Description:	The cover-image property identifies the described Publication Resource as the cover image for the Publication.
Applies to:	All raster and vector image types
Cardinality:	Zero or one

[patrik]

I'm a bit suprised over the lack of curiousity of this. Think about the fact that you can actually make a feature in an ebook that toogles full screen mode on and off while reading! Even if that feature may disapear after next firmware update it's sort of cool.

[compurandom]

Originally Posted by DNSB

Since this is a by design behaviour and complies with the epub3 spec, calling it a bug is a bit of drawing the long bow.

Who said I was calling this a /kobo/ bug?

I'm not sure whose bug it is actually, but it's a bug that kepub books end up on the device with an incorrect cover.

The cases are:
1) The book has no cover -- the kepub plugin should generate one except some of the books without a marked cover do have one; how is the plugin suppose to know the difference?
2) The book has an image as a cover -- the kepub plugin should wrap it in html and mark that as cover (it does not, and the first html file is treated as one)
3) The book has a cover that is part of the first html file (which might or might not be marked as a cover) -- how is the plugin suppose to know this and split it out? Maybe this is a bug in the book.

As a special case of #1/2, if the book contains a single html file, the kobo handles it correctly even if it doesn't have a cover or if the cover is an image.

A lot of the Gutenberg books have these problems.

[DNSB]

Originally Posted by compurandom

Who said I was calling this a /kobo/ bug?

Where did I say that you said it was a Kobo bug? What I said is that it is a by design behaviour -- one of the differences between epub2 and epub3.

Originally Posted by compurandom

I'm not sure whose bug it is actually, but it's a bug that kepub books end up on the device with an incorrect cover.

I've never seen that on a book purchased from Kobo. I have seen it in books converted from epub to kepub. Hence my checking the existence of the properties="cover-image" in the cover image entry in the manifest. If there is no cover image entry in the manifest, the fallback is the first file in the manifest.

Originally Posted by compurandom

The cases are:
1) The book has no cover -- the kepub plugin should generate one except some of the books without a marked cover do have one; how is the plugin suppose to know the difference?

If the cover image can be displayed when you have the book open to read, the cover image must be wrapped in HTML. Otherwise, you can have a cover image declared in the manifest but not used the epub text. FlightCrew will tell me the image is in the manifest but it is unused. I've seen this several times. A bit weird but that's life.

Originally Posted by compurandom

2) The book has an image as a cover -- the kepub plugin should wrap it in html and mark that as cover (it does not, and the first html file is treated as one)

If the cover image is properly declared in the manifest, it will be used as the cover. If it is not in the text of the book, it will not be displayed. See 1 above. If you want to add a cover image in the HTML portion of the book, see the ModifyEpub plugin for calibre.

Originally Posted by compurandom

3) The book has a cover that is part of the first html file (which might or might not be marked as a cover) -- how is the plugin suppose to know this and split it out? Maybe this is a bug in the book.

Again, the cover image must be correctly declared as such in the manifest. Anything else and you have a non-compliant epub. Please don't expect the authors of the convert epub to kepub routines to handle buggy epubs.

Originally Posted by compurandom

As a special case of #1/2, if the book contains a single html file, the kobo handles it correctly even if it doesn't have a cover or if the cover is an image.

A lot of the Gutenberg books have these problems.

I would agree that many older Gutenberg books give FlightCrew and epubcheck fits. After I fix the errors, the issues go away.

Basically, an old saw comes to mind. Garbage in, garbage out.

And please note that I keep referring to cover images entries in the manifest. A HTML file is not declarable as a cover image. Somewhat logically, a cover image must be an image file -- jpeg, png, gif or svg/xml are the only supported types in the specification.

[compurandom]

Originally Posted by DNSB

I've never seen that on a book purchased from Kobo. I have seen it in books converted from epub to kepub. Hence my checking the existence of the properties="cover-image" in the cover image entry in the manifest. If there is no cover image entry in the manifest, the fallback is the first file in the manifest.

I have (had) lots of epubs that had a cover image that the calibre editor showed marked as a cover image. When the book is converted to kepub and sent to the kobo, the kobo displays it on the home screen as a cover image, but when the book is opened, it treats the first html file in the book as the cover page, which is extremely annoying if it is suppose to be text to read.

The conversion from epub to kepub should wrap the cover image in an html file, even if that file is not included as part of the text.

The kobo wants an html for the kepub cover, not an image.
At least, that's what I've been told is in the kepub specs.

And yes, a lot of gutenberg books are a mess in general.

[davidfor]

Originally Posted by compurandom

I have (had) lots of epubs that had a cover image that the calibre editor showed marked as a cover image. When the book is converted to kepub and sent to the kobo, the kobo displays it on the home screen as a cover image, but when the book is opened, it treats the first html file in the book as the cover page, which is extremely annoying if it is suppose to be text to read.

The conversion from epub to kepub should wrap the cover image in an html file, even if that file is not included as part of the text.

The kobo wants an html for the kepub cover, not an image.
At least, that's what I've been told is in the kepub specs.

And yes, a lot of gutenberg books are a mess in general.

I seem to remember having this discussion here in the last couple of months.

The kepub specs are clear in how it treats the first HTML in the book. And it is also clear what it considers to be the cover for use elsewhere. And that these two things are not the same. There is absolutely no reason that the book has to have that cover image displayed anywhere. It could be because the cover image is optimised as a cover and a different version is displayed at the start of the book. Or it could be the book creator didn't want to display the cover.

When sending a book to the device using the extended driver, it attempts to work out what image is the cover and mark it as such. But, if it doesn't, it isn't an error, just sub-optimal for the device. The driver makes no attempt to do anything different with the first file. This is not the best, but the driver has always worked on the principal that the source file is suitable to be sent.

If you do a conversion to kepub, the handling is different. This will usually show the cover image as a separate file and as the first file in the book. You can turn this off, but the default is to have the cover page.

And, even in an epub, the defined cover image does not have to be used on the first page or anywhere else. The epub specs include how to say what is the cover image and nothing more. The various readers and apps are all deciding what to do. Some use the image directly, some, like Kobo, render the first page.

There is a bug in the initial report because the results seen are different depending on the navigation method. But, the behaviour of the first file is a design decision on Kobo's part.

[compurandom]

Just to be clear, I don't have a problem with kobo's design decision, and I don't particularly care about where and when the cover itself is displayed.

The problem is that something that is not a cover (the first html file) is being displayed as a cover when a cover html is not in the kepub.

Since discovering this bug (let's call it a bug in the kepub construction), I've taken a month or so to methodically go through my entire library and made sure all epubs have an html cover page.

It would be nice if the kobo extended driver did this for me, but in doing it myself manually, I discovered a great many kepubs for which this might actually be difficult. The only ones that are trivial are the ones that have an image as the cover currently and maybe possibly the ones that have no designated cover at all.

It also would be nice if there was a plugin (quality check?) that could check for epubs where the first html file possibly designated as a cover is too long to be a candidate cover or something like that. Or (assuming this isn't changed in the kepub driver), a way to search for epubs whose only cover is an image. Or maybe a way to search for (to eliminate from editing) epubs containing a single html file (which actually don't need an html cover apparently).

[DNSB]

Originally Posted by compurandom

Or maybe a way to search for (to eliminate from editing) epubs containing a single html file (which actually don't need an html cover apparently).

Once again, in the epub 2 or 3 specification, there is no such thing as a HTML cover. The cover image must be an image file in a supported format. Designating any other file as the cover image is an error and will be flagged as such.

My personal approach to epubs that contain a single HTML file is very simple. They get at least two HTML files. If it is a short story such as Block Party by Sharon Lee and Steve Miller where I generate the epub from the web page (see Block Party on Baen's web site) so I can read it on my ereaders, I generate a cover.xhtml and a content.xhtml file. Otherwise, I split at chapter breaks or in the case of some books where the author choose to handle the book as a single text flow (the edition I purchased of Robert Silverberg's Starborne as an example), I split at what I consider to be appropriate points.

Again, if the manifest entry for an image file correctly designates it as the cover image in content.opf, it does not need to be displayed so no HTML file needs to reference it. The ability to use the first HTML file as the cover image was, in my opinion, an attempt to handle the situation where no cover image is designated or a designated cover image did not exist and like most kludges, is neither pretty nor elegant.

[compurandom]

Originally Posted by DNSB

Once again, in the epub 2 or 3 specification, there is no such thing as a HTML cover.

Ok, so I grab a random epub generated by calibre itself.
I edit that epub with calibre's editor.

The first file listed is called "titlepage.xhtml" and is marked as a cover.

I didn't say COVER IMAGE. I said COVER.

[compurandom]

Ok, looking closer, there is a COVER PAGE and COVER IMAGE.

Apparently kepubs require the cover page.

I didn't realize that epubs could have both and just never looked for a cover image when I saw a cover page, but that makes a lot of sense.

So what I'm looking for is a search in quality check for epubs without a COVER PAGE, where the current search ("cover") presumably checks for epubs without both the cover page and cover image. I assume that if it has a cover page, it also has a cover image.

Epubs without cover pages seem to generate kepubs without cover pages, which do not work properly (unless there is exactly one html/xhtml file).