Aura HD whre does kebub renderer look for footer chapter title

[cybmole]

I am reading a compilation of short stories.

I noticed that there was no proper chapter split at the end of one story so I used sigil to insert the chapter break.

when I now read on Kobo, instead of seeing that story title in the footer and in the contents, I see only the new html file name once i reach that story.

here is part of the TOC file, I don' see any obvious cause for this behaviour. I did wonder if it is to do with html vs html, but I tried renaming all files to xhtml & that made no difference:

<navPoint id="navPoint-20" playOrder="20">
            <navLabel>
                <text>NIGHT TAXI</text>
            </navLabel>
            <content src="Text/Section0017.xhtml#heading_id_4"/>
        </navPoint>
        <navPoint id="navPoint-21" playOrder="21">
            <navLabel>
                <text>ANNUNCIATION SHOTGUN</text>
            </navLabel>
            <content src="Text/Julie%20Smith%20-%20New%20Orleans%20Noir_split_006.html"/>
        </navPoint>
        <navPoint id="navPoint-22" playOrder="22">
            <navLabel>
                <text>LOOT</text>
            </navLabel>
            <content src="Text/Section0001.html#heading_id_4"/>
        </navPoint>

on kobo in toc , and in chapter footers I see ...
NIGHT TAXI
Julie_Smith - New_orleans_noir-split_006.html
LOOT

i.e I don't see the middle story title - i.e. it is not honouring the code line
<text>ANNUNCIATION SHOTGUN</text>
what do I need to tweak to fix this ?

NB if I open the book in ADE, all the TOC entires look OK so I think it's a kobo footer issue, possibly a plug issue within the convert epub to kepub code ? [EDIT - ignore that last remark- I did not send book via that plug in - I have it in kobo android app via dropbox, so it is epub not kepub- but the android app gives it a kepub style footer automatically ]

I can send it via the plug in to my e-reader if necessary & see how it behaves there - if not one has an obvious explanation

I have removed it & resent it via dropbox 3 or 4 times now, after trying various tweaks in Sigil, I still can't find an explanation for this behaviour. It may be a fluke for one book only though because I've not previously noticed it when reading other books

update: starting again at that code excerpt, I see that the problem title is missing this bit on the end of the content link tag:

#heading_id_4

but in my latest version, after having had sigil rebuild the toc - I don't have that #heading bit on any of the toc entries, so that could be another red herring ?

[davidfor]

Sorry, are you seeing this as a problem on the Aura or the Android app? I don't know how the Android app works.

As an epub on the Aura, that TOC should be fine. As a kepub, it should be as well. In both cases, the NCX is read during the initial processing of the book. This is then stored in the database and used for the TOC when reading the book and the chapter names in the footer for a kepub.

But, I can see two differences between the good and bad entries. Firstly the good entries both refer to anchors. The bad entry has escaped blanks in the file name. It could be the lack on an anchor in the latter, but it is more likely the spaces. Renaming the file to remove the spaces might fix it.

[cybmole]

i was seeing it on the tablet app. I just sent it ia the kepub plug iin to my Aura HD & ts fine on there, but that is after rebuilding the toc with sigil. so I think I've fixed it, I am jsut not sure what fixed or what was actually wrong in the first place..
I think if I sent it back to the android app it will still be iffy though, [ but I've run out of steam, now ! ]

so maybe that app has an issue with what you call escaped blanks - that would be the %20 stuff ? - or i'ts to do with anchors - that would be the #heading_Id

I do see that after rebuilding the toc in sigil , there are no anchors anymore?

the working ( on Aura HD) code now looks like this:

 <navPoint id="navPoint-17" playOrder="17">
      <navLabel>
        <text>NIGHT TAXI</text>
      </navLabel>
      <content src="Text/Section0017.xhtml"/>
    </navPoint>
    <navPoint id="navPoint-18" playOrder="18">
      <navLabel>
        <text>ANNUNCIATION SHOTGUN</text>
      </navLabel>
      <content src="Text/Julie%20Smith%20-%20New%20Orleans%20Noir_split_006.xhtml"/>
    </navPoint>
    <navPoint id="navPoint-19" playOrder="19">
      <navLabel>
        <text>LOOT</text>
      </navLabel>
      <content src="Text/Section0001.html"/>
    </navPoint>

if that works everywhere except for within the android app then I can live with that !

I can't actually think what else to test it in, because only the kobo app readers does chapter title footers anyway ?

[davidfor]

Originally Posted by cybmole

i was seeing it on the tablet app. I just sent it ia the kepub plug iin to my Aura HD & ts fine on there, but that is after rebuilding the toc with sigil. so I think I've fixed it, I am jsut not sure what fixed or what was actually wrong in the first place..
I think if I sent it back to the android app it will still be iffy though, [ but I've run out of steam, now ! ]

so maybe that app has an issue with what you call escaped blanks - that would be the %20 stuff ? - or i'ts to do with anchors - that would be the #heading_Id

Yes, that is correct. Spaces in file names are always a problem if they aren't handled properly.

I do see that after rebuilding the toc in sigil , there are no anchors anymore?

the working ( on Aura HD) code now looks like this:

Sigil doesn't put the anchors in if the the heading it refers to is the first in the file.

if that works everywhere except for within the android app then I can live with that !

I can't actually think what else to test it in, because only the kobo app readers does chapter title footers anyway ?

It should also be used for the TOC. But, it sounds like it is only the Android app that has the problem.

[cybmole]

I've ditched that book rather than waste hours on the puzzle.
the displayed TOC I was fine in both n ADE & in calibre viewer after I did a toc rebuild in Sigil, & was fine on the Aura HD also.

FWIW the Kobo android app ( with a standard epub imported) works like the kepub renderer on the reader. It clearly opens only one chapter file at a time, because you see a very short " thinking" spinning icon whenever a new long-ish chapter loads, & then the footer data is computed for that chapter + your current screen settings. i.e. the number of pages in the footer is the actual number of screens needed to display that chapter with your current font size choices.

So the only places it can get footer info from is inside that chapter file or in the TOC file, which I guess it also keeps in memory. Possibly it gets it's footer text from the toc & not from the chapter file _ I@d have to deliberately alter the labels in a toc files to test that

I did notice that the android app was consistent in that it messed up both the footer & the relevant TOC entry when you pull down the toc shortcuts via settings ( works differently to the e-readers ) _ you have a pull down tab that does toc & also does the link to annotations. teh software must have some "rle" that sasy flal back to using the html file name if you can't get a proper "chapter title" but it is not at all obvious why it glitched on that one file. all that was "special" about that file was that I did a manual split in sigil because the book had 2 short stories within the same chapter file.

navigation within compilations of short stories can be more problematic than novels, esp. if they are just glued together from different sources. What goes in the Toc could be each story title, or each story title+ author, or both as separate entires, I've seen all of those variants. IT gets messier if some stories are a single chapter but some have chapters of their own...

[jackie_w]

When you corrected the TOC ncx did you resend the new epub to just overwrite the old or did you fully delete the old (using the Kobo app's delete facility) before attempting the re-send? If the former perhaps the Kobo app is 'remembering' the old TOC ncx details rather than re-reading. It's just a thought - I have no factual observations to offer.

[cybmole]

Originally Posted by jackie_w

When you corrected the TOC ncx did you resend the new epub to just overwrite the old or did you fully delete the old (using the Kobo app's delete facility) before attempting the re-send? If the former perhaps the Kobo app is 'remembering' the old TOC ncx details rather than re-reading. It's just a thought - I have no factual observations to offer.

well I used " delete book" within the app, then download from dropbox to tablet, then import book. But who knows what fragments the database hangs on to.

Also, there's a lot of steps to check if I'm testing properly. like: 1. did I actually backup calibre to local dropbox folder. 2. did dropbox actually sync that to cloud, before I re-download to tablet... a lot of checking of file dates, to be sure that I'm testing the newly edited version & not just re-testing the old version. and I was being lazy & not also sending each edit to the aura HD to see how changes registered on that.

the main puzzle was not "can I fix it" , it was " why is it not already working".

my best theory ( given that I've now binned the dodgy source & moved on) is that I had that book for ages & I'd partially cleaned it myself in an old version of sigil, adding in some splits where 2 stories were in same "chapter". That was back in the day when sigil expected you to fix the toc by hand, mostly. so it was something to do with how I'd done the splits....

I did get a feeling, when I started to read it, that I'd read the opening short story once before, so probably I did a quick tidy of the book ages ago, ( added a couple of needed splits) , read a only bit of it , abandoned it, came back to it 2 - 3 years on when having a clearout....

Then for some reason I'd chosen this one & a few similar short story compilations as tablet testers so it has been travelling around via google play books, dropbox , on & off Kobo Arc, in & out of various Kindle Fire epub readers... & hence in & out of various android folders....

The book is scrapped now anyway, I just hoped someone would spot an obvious flaw in the posted code, that I was blind to.... or that someone would say, OH Yes, that happened to me once & it was because of .....

There's one simple instructive test for when I can be bothered. (maybe tomorrow)

Pick a well formed book.
change the nav value text for at least one chapter by directly editing the TOC in sigl or calibre editor,
(so that it differs from anything in the <head> section of the corresponding xhtml chapter file,)
then send that to aura via kepub converter and to tablet via calibre companion or dropbox,
then see what shows in footers on screen & what shows in the TOCs.

that should answer the thread title "where does renderer get footer info from "

[cybmole]

a new test

so to puzzle out more of my own ocnfusion I took a different book & delibarately picked an awkward one whth had 2 <h2> tage per chapter.

then I added the word test into the toc file
so I had this code:

<navPoint id="navPoint-2" playOrder="2">
      <navLabel>
        <text>1</text>
      </navLabel>
      <content src="Text/chapter01.xhtml"/>
    </navPoint>
    <navPoint id="navPoint-3" playOrder="3">
      <navLabel>
        <text>THE BEGINNINGS OF CHRISTIAN SCRIPTURE test</text>
      </navLabel>
      <content src="Text/chapter01.xhtml#sigil_toc_id_1"/>
    </navPoint>

I sent that via the kepub plug in to aura HD.

What I see in the footer for that chapter is the number 1 - so it seems to take the 1st toc entry that links to that xhtml files and use that as it's foot label.

that book also had a chapter called conclusion. Only one toc entry for that chapter, so I changed it to to say conclusion test, and that is what shows in the footer on the aura. so the renderer uses what is in the toc, not what is in the chapater html file.

in hte aura toc I ahve both of the entires shown above & both go to the same place.

so that seems well behaved. I've dumped a copy into drop box so I will swee waht the kobo tablet app makes of it later.

Also, looking on my tablet, I see that an old copy of the previous problem boo is still uploaded to my google play books account. Now there's no way to get it back out of google play to examine the code, but what I think I see is that google books ignores the actual toc & compiles its own, by picking up what is in the 1st header tag of each html file in the epub

l. So where there is a header tag for story title, followed by another one for author, google just shows the 1st one. and where there are 2 stores in one xthml files, it does not show a link to the 2nd story, so it is not checking all the <h2> tags, its just takng 1st one it finds. google books does not do footers so no more clues there.

A proper test would mean making a test case book with all sorts of stuff in toc ,then uploading it to google play & comparing display with all the other options but that is straying off topic. That is something for another rainy day.

[davidfor]

Originally Posted by cybmole

a new test

so to puzzle out more of my own ocnfusion I took a different book & delibarately picked an awkward one whth had 2 <h2> tage per chapter.

then I added the word test into the toc file
so I had this code:

<navPoint id="navPoint-2" playOrder="2">
      <navLabel>
        <text>1</text>
      </navLabel>
      <content src="Text/chapter01.xhtml"/>
    </navPoint>
    <navPoint id="navPoint-3" playOrder="3">
      <navLabel>
        <text>THE BEGINNINGS OF CHRISTIAN SCRIPTURE test</text>
      </navLabel>
      <content src="Text/chapter01.xhtml#sigil_toc_id_1"/>
    </navPoint>

I sent that via the kepub plug in to aura HD.

What I see in the footer for that chapter is the number 1 - so it seems to take the 1st toc entry that links to that xhtml files and use that as it's foot label.

There was some discussion on this here last year. From memory you are right. The chapter at the bottom is the first TOC entry in the file. But, I don't remember if the page count was done for the file or for the chapters in it.

that book also had a chapter called conclusion. Only one toc entry for that chapter, so I changed it to to say conclusion test, and that is what shows in the footer on the aura. so the renderer uses what is in the toc, not what is in the chapater html file.

Yes, the Kobo e-ink devices use the NCX for their navigation. But, they read it when the book is first put onto the device and load it into the internal database. The navigation actually uses the database entries rather than reading the NCX when you are reading the book.

in hte aura toc I ahve both of the entires shown above & both go to the same place.

That should only happen if they are on the same screen. I have quite a few books with a main chapter heading for the file and sub-chapters within. The navigation works as expected. But, it will go to the start of the file if the anchor doesn't exist in the file.

I can't comment on the android and google play behaviour as I don't use either. Well, other than saying it sounds like Google got it wrong.

[cybmole]

hte next test should b to create book with more chaper files than toc enttires. to confirm that the footer counts pages between toc nav points, not pages in current xhtml file, I expect wtat is that a test would show.

PS maybe I was wrong about google books. I just ( on the PC) uploaded that current test book & opened within google books & it does seem to have the complete toc. I see the word ""test" where I'd added it to the toc file. and I see the double entry of chapter name & chapter number, as per the code extract that I posted previously.

The case FOR using google books is that it will sync your place in book between all devices, even for books you upload yourself, and you can choose to have an offline copy stored on tablet so you can still read with wifi-off. It will sync when it next has the opportunity. But, it limits to your PCs & devices that can talk to google servers, so no Kindles.

here is how to use it from within chrome:
http://google.about.com/od/androidti...Play-Books.htm


PS I thought I'd deleted all copies of the original test book, but then I saw I still had an old version in dropbox, so I grabbed that & changed all the xhtml file names which contained %20 . Once I replaced those with simple names like test1.xhtml, the original bug disappeared!. Sigil nowadays is pretty smart with such things; if you rename a chapter file it fixes the toc for you. ( I think the older version id not do that )

So it is best to avoid any %20 spaces in chapter file names in books, if you plan to read them on Kobo. I think that is diagnosed to my satisfaction now, so I really can bin all verions of that annoying boo!

[cybmole]

update 2? or is that 7 by now ??

another similar book,

this one has a chapter faile with jsut a map image at start of book, and has a lsit of contributors page at athe abck.

I don't have a toc entry for either of those pages.

so non-kobo devices will , when you select table of contents< shwo only hat is in the toc.

KObo on tablet, so proably "kepub'd" books sent to ereader also, reackon they need somethign for those 2 pages so the file anmes get put into the toc & into the footer instead.

I suppose there is some logic for that, & their design does not cater for awkward folks like me who like to mimimise the actual toc & one have what I think are useful pointers in there. I guess that as the database enties are being added fo the new book , there are fields to be fiilled & something has to go into them


so I now wonder, & I may test, what happens with a book that has a very long chapter, which calibre has split into 2 x xhtml files in order to honour the 260k max rule. what will Kobo show as you more onto the 2nd part of hat split chapter ?, and what will it put into the toc /

place your bets.....

[davidfor]

Originally Posted by cybmole

update 2? or is that 7 by now ??

another similar book,

this one has a chapter faile with jsut a map image at start of book, and has a lsit of contributors page at athe abck.

I don't have a toc entry for either of those pages.

so non-kobo devices will , when you select table of contents< shwo only hat is in the toc.

KObo on tablet, so proably "kepub'd" books sent to ereader also, reackon they need somethign for those 2 pages so the file anmes get put into the toc & into the footer instead.

I suppose there is some logic for that, & their design does not cater for awkward folks like me who like to mimimise the actual toc & one have what I think are useful pointers in there. I guess that as the database enties are being added fo the new book , there are fields to be fiilled & something has to go into them

From the books I've looked at, purchased kepubs tend to have a TOC entry for all files. But, not having one doesn't break anything. The footer just has a blank for the name.

so I now wonder, & I may test, what happens with a book that has a very long chapter, which calibre has split into 2 x xhtml files in order to honour the 260k max rule. what will Kobo show as you more onto the 2nd part of hat split chapter ?, and what will it put into the toc /

The "260K max rule" is a recommendation for epubs being handled by the Adobe RMSDK. As I understand it, it was a recommendation to improve performance on older devices with lesser RAM and CPU. I have a 30+ chapter epub that I combined the chapter files into a single 1.5MB file. The epub says 494 pages. This works as both an epub and kepub on my Glo. Both take longer to open than the individual file version. The kepub doesn't seem to have any problems. But, the epub gets very slow towards the end.

And apparently my memory failed me the other day about how the chapters and numbering were handled in the kepub version. For the single file version, the footer works the same as for the file per chapter version. The current chapter name is shown and the page numbering is for the chapter.

[cybmole]

ok - so can you predict what happens with a split chapter i.e. if we have
ch1-part1.html
ch1-part2.html
ch1-part3.html
ch2-complete.html
in epub
but toc only pointing once at the 1st & last files

what footer titles & counts will we see, if we sideload that through the kepub driver, & will we see extra generated TOC entries for the middle 2 fiels ?

PS I leave the 260k limit default intact in calibre, just in case I ever switch to a reader that still needs that. I still have one old Sony reader for emergencies!

there's another case. I have some books where the chapter number is always in a separate filel from th chapter text - usually caused calibre's default structure detection rules when silly people use chapter as a CSS class

so you get
ch1-0.html
ch1-1.html
ch2-0.html
ch2-1.html

etc.
in the 1st file of each pair is just the chapter number or title, in the 2nd file is the body text.

and that is such a pain to reverse - I never figured out how to automate recombining each pair so I leave it be, usually. I think the kepub renderer is not going to like that setup.

[davidfor]

Originally Posted by cybmole

ok - so can you predict what happens with a split chapter i.e. if we have
ch1-part1.html
ch1-part2.html
ch1-part3.html
ch2-complete.html
in epub
but toc only pointing once at the 1st & last files

what footer titles & counts will we see, if we sideload that through the kepub driver, & will we see extra generated TOC entries for the middle 2 fiels ?

There was a discussion on this late last year. I think the conclusion was that there needed to be a TOC entry for each file. If there wasn't, the book wasn't handled correctly. I can't find the thread quickly, but the poster included a book called "Page numbers Test - Yo.epub". The copy I have is from 18th of November last year, so the discussion probably happened about then. But, it might have been in the extended driver thread.

PS I leave the 260k limit default intact in calibre, just in case I ever switch to a reader that still needs that. I still have one old Sony reader for emergencies!

there's another case. I have some books where the chapter number is always in a separate filel from th chapter text - usually caused calibre's default structure detection rules when silly people use chapter as a CSS class

so you get
ch1-0.html
ch1-1.html
ch2-0.html
ch2-1.html

etc.
in the 1st file of each pair is just the chapter number or title, in the 2nd file is the body text.

and that is such a pain to reverse - I never figured out how to automate recombining each pair so I leave it be, usually. I think the kepub renderer is not going to like that setup.

I would probably edit the source to fix that first. Or play with the chapter detection If the source uses heading tags, then getting rid of the text checks will prevent the split. But, it's easy to merge two files in Sigil or the calibre editor.

[cybmole]

it is easy to merge 2 fiiles yes, but not foe each of 50+ chapters.

It took a long time for me to realise that it was probably calibre structure detect casugin the false splits. Its probably only an issue in older books, already read, for which I kept only the "read" version & not the original source

the book will always be readable though? it's just the footer that may look a little strange ?