E-readers not recognizing chapters

[JeanneLaska]

Hi,

I have both a specific question (see title) and a more general, theoretical one. Let's see what you can tell me on either topic.

Sigil is known as a WYSIWYG editor. Except what turns out, is when Sigil shows you a well-formatted, problem-free ePub, a given e-reader might well show you something quite different, with layout and reading problems coming seemingly out of nowhere. To be honest, I'll even say that what you see on Sigil is never exactly what you get on an e-reader/e-reading app (fortunately, the difference isn't always a problem). Which makes anticipating problems difficult. Especially since said problems are often specific to a single device, and the number of different e-readers is still increasing. In other words, I'll test my ePubs on a Nook, but that gives me close to no idea what the same ePub will look like on a Kobo or a Sony.

And still I like Sigil, and I don't really believe that there's an ePub creator out there that's significantly better. I guess my goal is just to know what and how to change things in Sigil, which may not make the ebook look any different when opened with Sigil, but will actually improve its reading quality on this or that e-reader.

For example, an ebook I made showed huge margins on the Kobo (but didn't on Sigil, Calibre, Nook, or when converted to Mobi for the Kindle). It seems that my style sheets contained an info about page margins which many e-readers and e-reading apps/software ignored, but the Kobo took to heart.

I think a senior ebook maker (which I'm definitely not) should have a list of such "invisible" things to fix. What do you think? Does any of you work that way?

Right now, the thing that bugs me most is actually common to the Nook and Kobo (as far as I can tell). Not only does my ePub show a set number of pages that does not adapt to the e-reader's settings, but the whole ebook is considered as one vast chapter. Even though chapters are actually separate files in Sigil. Can I do anything so the Nook doesn't tell me absurd things like "There are 137 pages left in this chapter"?

My Kobo-owning friend reported that chapters were properly recognized in his Kobo-bought ebooks. (So there is a way to make it work.)

I've also had another problem, similar to the one reported in the following thread: Glitch with page numers (!) in Digital Editions, but the truth is I'd like a solution I can implement in Sigil specifically.

Thanks to everybody who may have an opinion on any of this.

[DiapDealer]

There will probably never be a WYSIWYGOEROT (what you see is what you get on every reader out there) editor. WYSIWYG simply means that you don't have delve into code (html/css) if you don't want to.

Learning the idiosyncrasies of the various devices on the market is an ongoing and mostly personal, hands-on endeavor. People share of course, but there is no central repository for the knowledge.

In this particular case, I suspect, the "pages left in chapter" feature offered by Kobo is more or less restricted to their slightly proprietary kepub format. Which—as it it seems I've been typing quite a lot lately—is NOT epub... no matter how similar the file extensions appear to be. I suspect that the Kobo-bought ebooks that it's working for for your friend have in fact, been downloaded as keypub files and not epub.

I can assure you that "pages left in chapter" is not any sort of standard ePub functionality (ePub meaning ePub2... which is what Sigil creates).

[mrmikel]

There is a Kobo desktop app. Might be worth having so you can check it before it is sent to a device.

You may be suffering from non-breaking spaces which Sigil will put into your text. Use search and replace to pull them all out before saving. You can always put them back in those few cases where you need them.

Also, drop caps, if not done well, can cause odd behavior in my Sony.

You might compose a test epub for checking and throw in the kitchen sink....one item at a time, then observe in the reader app. Maybe you can track down what is causing a problem. Take your stylesheet from your problem child and copy each line into your test epub one at a time until it goes bingo!

[PeterT]

Kobo Desktop only supports material obtained from the Kobo store.

[JSWolf]

I've not found a problem on my Sony if the ePub looks good with ADE 1.7.2. I keep that old version around for testing. I've also used Bluefire Reader (uses ADE) for the iPad and iOS without a problem.

Do you actually have a proper ToC in the ncx file or are you just doing it via a list of links?

As for Sigil being WYSIWYG, it's not fully so. Also, Sigil has issues sometimes with the display of the ePub due to QT that it uses to render the ePub. That's why you need ADE on your computer to check the ePub.

[JeanneLaska]

Thanks everybody for your input. You are confirming some things I suspected.

I will definitely try and get as many e-reading apps to test my product.

Originally Posted by DiapDealer

I can assure you that "pages left in chapter" is not any sort of standard ePub functionality (ePub meaning ePub2... which is what Sigil creates).

Good to know. The Nook does that as well, though.

Originally Posted by JSWolf

Do you actually have a proper ToC in the ncx file or are you just doing it via a list of links?

Both. Yes, those chapters definitely exist.

[JSWolf]

Originally Posted by JeanneLaska

Both. Yes, those chapters definitely exist.

If the eBook is in ePub, it does bug me that there is an internal and external ToC and I find it highly ass-backward to have an entry in the external ToC called Contents to take me to the internal ToC. This is stupid (IMHO). I'm already at the external ToC. Why would I then want to go to the internal ToC (which has no use at all in an ePub)? I would not. I do strip out the internal ToC (worthless in an ePub) and I remove the entry in the external ToC that goes to the internal ToC if there is one.

[Jellby]

Originally Posted by JSWolf

I'm already at the external ToC. Why would I then want to go to the internal ToC (which has no use at all in an ePub)?

Because the internal ToC may have additional information like illustrations, summaries, authors/dates...

Of course, it could happen that the internal ToC is simply a duplication of the external one, in that case I agree with you. But my point is that an internal ToC is not necessarily a bad thing.

[theducks]

I agree with Jelby, When you want to embellish a TOC (which the NCX does not allow), then the internal TOC is a good thing)
As for 'A list of illustrations': couldn't that be s separate HTML file and that file, be linked to the TOC?

[JSWolf]

Originally Posted by theducks

I agree with Jelby, When you want to embellish a TOC (which the NCX does not allow), then the internal TOC is a good thing)
As for 'A list of illustrations': couldn't that be s separate HTML file and that file, be linked to the TOC?

You could do a list of illustrations in the NCX ToC.

Two levels and boom, done.

[theducks]

Originally Posted by JSWolf

You could do a list of illustrations in the NCX ToC.

Two levels and boom, done.

Aren't there devices that don't support nested (NCX) TOC?
So while it is technically allowed. 'Real World' rears it's head frequently.

Overly loose specs are the bane of content developers

[JSWolf]

I know of no standalone eInk reader that does not work with the NCX.

[theducks]

Originally Posted by JSWolf

I know of no standalone eInk reader that does not work with the NCX.

You misunderstood me. There are readers that don't allow the NCX to be nested (Flat NCX only)

[Jellby]

Originally Posted by JSWolf

You could do a list of illustrations in the NCX ToC.

In theory, you could have a list of illustrations as a secondary navList in the NCX (as I said here, see this book too). I doubt it works anywhere, though, but it's the right way™ to do it.

[cybmole]

my sony reader does not like a generated TOC which has both H1 & h2 links pointing to the same xhtml file

e,g,
<h1>PART 1</h1>
followed by
<h2>chapter 1</h2>
on the same "page"

OK in sigil viewer
but sony TOC will only display one of the 2 links