Kobo Firmware 3.11.0

[rcentros]

Originally Posted by Nick_1964

Also: By editing the file .kobo/Kobo/Kobo eReader.conf on your device and changing (adding this section if not present) the FeatureSettings section:

[FeatureSettings]
FullScreenReading=true
After this a new menu entry in the Reading page of the Settings is available, called Page layout, where one can show/hide the header/footer.

Excellent! Thank you very much. I like my Glo much, much more now.

[khalleron]

Originally Posted by Nick_1964

Also: By editing the file .kobo/Kobo/Kobo eReader.conf on your device and changing (adding this section if not present) the FeatureSettings section:

[FeatureSettings]
FullScreenReading=true
After this a new menu entry in the Reading page of the Settings is available, called Page layout, where one can show/hide the header/footer.

Does this work on the H2O as well, because I'd really like to get rid of the header?

[rcentros]

Originally Posted by khalleron

Does this work on the H2O as well, because I'd really like to get rid of the header?

Not speaking for Nick, but I'm guessing they have the same software and should work the same? (??) (Just a guess.) Be aware that this particular hack (if it does work on the H20) not only gets rid of the header, but also gets rid of the footer -- so you have no page number visible either. (It can be toggled on and off for a quick look, if you want.) Seems that I read of another hack on the H20 (but not on the Glo) that would allow you to remove just the header -- but I may be wrong.

[arspr]

Originally Posted by khalleron

Does this work on the H2O as well, because I'd really like to get rid of the header?

Sure, I do have it enabled. In general all the Kobo devices have the same set of features (and bugs). They just look the same, just bigger/smaller, with higher or lower resolution.

Just remember that it kills the header AND the footer.

If you just want to remove the header your best option is using epubs instead of kepubs.

[melovesflying]

Recently updated my Aura to the latest firmware and I noticed some slowdown, especially when turning it on and changing the font size using two fingers.

[cybmole]

i have found what I'll call a "long chapter bug" with the new page numbering options. I don't think it's been reportesd already btu I could not face reading the entire 11 pages to be sure..
anyway. I ahve a book with some 200+ page chapters which have been split into smaller 100+ page sections ( maybe by calibre but I think its in the original epub)
you'll see this in any of the James Mitchener epics I think.

now with 3.08 & earlier, loading it via the kepub driver. you'd seechapter name and page x of y numbering in the footer , but when you got to the 2nd part of a chapter i.e. to where a new html file kicked in the chapter name would disappear from the footer and the numbering would restart at 1 of xx.

In 3.11 if you turn on whole-of-book page numbers, the algorithm that calculates what whole-of-book page you are on can't cope with the above; going back and forth from last page of a chapter to 1st page of a new chapter ( in a book that has split chapters i.e. has more chapter files than it has chapters in the toc ) introduces 100+ page number jumps.
In my book, don't think the story text order was affected but I edited the source & merged all the problem chapters & reloaded the kepub.epub . the book page numbers flow OK now.

It should be fairly easy to produce a test case if anyone is interested. I don't think it is necessary to find a book with super long chapters. Just take say a 3 chapter book and then artificially split the 2nd chapter, say with sigil. then load that book - which will now have 4 x html files, onto the reader & see hat happens with page numbers when you use toc to jump to a specific chapter.
I am guessing that the page number calc uses the toc to ask how many other chapters there are, and calculates pages for one file per chapter - so that split chapters do not get counted correctly.
as the whole of book page number feature is new to this firmware release, it will not show in older versions.

[JSWolf]

Originally Posted by cybmole

i have found what I'll call a "long chapter bug" with the new page numbering options. I don't think it's been reportesd already btu I could not face reading the entire 11 pages to be sure..
anyway. I ahve a book with some 200+ page chapters which have been split into smaller 100+ page sections ( maybe by calibre but I think its in the original epub)
you'll see this in any of the James Mitchener epics I think.

It's not an actual bug. The way the chapter names are gotten is from the ToC. The second file of the split chapters don't have a ToC entry. So the software doesn't know it's a continuation of the chapter. It doesn't know what that file is other than an XML file for display. You cannot expect that sort of thing to work as you want. Combining the split chapters back into one chapter is the only way there is to fix this.

[cybmole]

Originally Posted by JSWolf

It's not an actual bug. The way the chapter names are gotten is from the ToC. The second file of the split chapters don't have a ToC entry. So the software doesn't know it's a continuation of the chapter. It doesn't know what that file is other than an XML file for display. You cannot expect that sort of thing to work as you want. Combining the split chapters back into one chapter is the only way there is to fix this.

it is reasonable that the firmware does not know what name to display in the footer for split chapters.

it is not reasonable software design to create a situation where turning from last page of (split) chapter x to 1st page of chapter x+1 causes a 300+ page count jump. I found that I could go FORWARD one page and according to kobo I'd gone from page 1200+ back to page 900+
and in one case for sure, this is how the retail epub was published, it's not that calibre has introduced the splits in order to maintain some 260k or whatever limit. I've a feeling I have an Anne Rice book somewhere that also was published with splits in very long chapters. If an author wants a 200 page chapter, they should be able to have one without the publisher's screwing up

it seems to me that Kobo, in typical Kobo fashion, have added a feature (all of book page numbers) which they have not tested against a large enough sample of retail books. I'm guessing that depending on direction of page turn, kobo sometimes counts back from end of book and sometimes counts forwards from start. but miscounts the splits as it goes.

that is just crass programming, and ADE for example is perfectly able to maintain a sensible page count throughout & not get confused.

I bet the page numbering is also well behaved in epic kindle books, even if some chapters have been split .

as it maybe affects <0.1% of books, I doubt Kobo will ever fix it though
perhaps others can check their longest books for other examples.

[JSWolf]

Originally Posted by cybmole

it is reasonable that the firmware does not know what name to display in the footer for split chapters.

it is not reasonable software design to create a situation where turning from last page of (split) chapter x to 1st page of chapter x+1 causes a 300+ page count jump. I found that I could go FORWARD one page and according to kobo I'd gone from page 1200+ back to page 900+
and in one case for sure, this is how the retail epub was published, it's not that calibre has introduced the splits in order to maintain some 260k or whatever limit. I've a feeling I have an Anne Rice book somewhere that also was published with splits in very long chapters. If an author wants a 200 page chapter, they should be able to have one without the publisher's screwing up

When you go from this split chapter to the next chapter, does the page number become correct? My guess is that they are getting the page number the same sort of way they are getting the chapter number (via the ToC) and since this split has no ToC entry, the software is a bit confused. I do agree that this is a bug (page number being wrong).

[cybmole]

I've edited that book now, so I cant easily repeat tests for you, & how would I know which reported page number was correct - except by turning pages from 1 forwards & counting ? The total pages number was always the same ( 1500+ ) but maybe that was pre-computed.

Anyway, here's a new variant.
same feature, different (more popular) books, different bug:
Stephen King's 7 volume Dark Tower series. Each book is split into stanzas, each stanza is split into multiple short chapters. the TOC is at chapter level. but the files structure is one html file per stanza.
so in normal reading you see new chapters start anywhere on a page...

in chapter numbering, the footer works at chapter level, not at stanza level - as soon as you turn to a page that has a new chapter title somewhere on that page, you get that chapter name 1 of x in the footer.
But in book numbering, you are on page x of y and you stay on page x of y all the way through each chapter, then there's a jump, so if I am coming out of a 6 page chapter I see a sudden jump to page x+6 of y.
I've only looked that the book I am currently reading but I think all 7 books in the series have similar coding and structure.

So in this case e have a one to many relationship between html files and toc entries. in my previous epic book example it was the other way around, I had a many ( well 2 actually) to 1 relationship between some html files and a single toc entry.

It just so happened that i had these 2 books and no others on the device when I did the 3.8 to 3.11 upgrade.
I guess there is an outside chance that books added after the Fw upgrade will behave better and that its an effect of the books being indexed by 3.8 fw then viewed in 3.11.

But I'd rather be reading than debugging. I am posting really to see if others can replicate. Maybe when I finish this book I will delete it, reload it, see if it behaves any different...

( I was not intending to even go to 3.11 but my son wants to loan this kobo at the weekend with a view to buying his own one if he likes it, so I figured I should get it fully updated for him, rather than have him do it accidentally from playing with wi-fi options )

[davidfor]

@cybmole: This is not really a bug. Your books do not follow the specs for kepubs. There is supposed to be a ToC entry for each file in the spine. If you publish through Kobo, if there is no ToC entry for a file in the spine, one will be generated. This is done by the Kobo content management system, not by the device. What you are seeing is the code handling an out-of-spec book the best way it can.

They aren't explicit about the other way: multiple ToC entries for different parts of one same file. I think they are expecting a 1-1 relationship. I don't think I have seen a purchased kepub that did not have a 1-1 relationship between the ToC and the files. And I have seen a few recently where the ToC was auto generated for a couple of chapters.

Your examples are all sideloaded books converted by the extended driver in calibre. If you find an example in a purchased kepub, you should scream. But, Kobo don't really support sideloading kepubs. They do suggest it to authors as way to check formatting of the book, but it is not intended for daily reading.

Is this a problem that Kobo should handle better? Yes. Will they fix it? I don't know. But, they won't if they don't know about it. A clear description of the problem and the expected results is needed. And a test case is always a good idea.

[cybmole]

ok thanks, my examples are converted epubs as you noted.

if any one owns the kobo store kepubs of the Stephen King books, it would be good to hear how they behave; for me I'll stick with the better behaved page number by chapter option.

I think I'll get into the habit of repairing any long chapter splits that I come across also.
the aura HD has no problem handling a 250 page chapter, I guess it must have some upper limit but I don't know what that would be.

[Nick_1964]

Ok, seems that 3.12.0 is out.. https://www.mobileread.com/forums/sho...postcount=1089

[akorx]

Hi guys,

We can adjust the brightness when we put one finger on the screen and move it either up and down... I don't like this function, is there a way to disable it ?

I just want to keep the "slider" (I'm french and I don't know if "slider" is the good word).

[JSWolf]

Originally Posted by akorx

Hi guys,

We can adjust the brightness when we put one finger on the screen and move it either up and down... I don't like this function, is there a way to disable it ?

I just want to keep the "slider" (I'm french and I don't know if "slider" is the good word).

It's only if you slide up/down on the leftmost edge of the screen. It's very easy not to do this accidentally.