Kobo Firmware 3.11.0

[RoninTech]

Originally Posted by PeterT

I actually use Kobo Utilities to automate storing the reading location on my Kobo; then it's trivial to reload and restore reading position in case of a crash.

How do I use it to do that Peter? Nothing jumps out at me when looking through the various settings.

[Nick_1964]

Originally Posted by Anak

Most of the bugs/issues you refer to are 'implementation bugs' by Kobo as they have nothing to do with the render engine (here: RMSDK).
If the same bugs and/or issues also surface on Sony, Icarus, Bookeen and other ereaders that use RMSDK then those bugs are RMSDK related.
If not, those bugs, issues or problems are created by Kobo.

I agree with you,but some reactions here are, it is the fault of the RMDSK while I say, it is not important what lays underneath it, I buy the reader and there is Kobo on it, so they must fix the bugs,no matter where they exist.
But then I again "hurt" people that react personal.
It is easy to step on toes..

[PeterT]

Originally Posted by RoninTech

How do I use it to do that Peter? Nothing jumps out at me when looking through the various settings.

See this post --> https://www.mobileread.com/forums/sho...2&postcount=14

[davidfor]

Originally Posted by Anak

Most of the bugs/issues you refer to are 'implementation bugs' by Kobo as they have nothing to do with the render engine (here: RMSDK).
If the same bugs and/or issues also surface on Sony, Icarus, Bookeen and other ereaders that use RMSDK then those bugs are RMSDK related.
If not, those bugs, issues or problems are created by Kobo.

Are any of these using the same version of the RMSDK as Kobo? Kobo is now using RMSDK 10, but not the latest build. Up until they upgraded to this earlier in the year they were using a very version that was at least two years old. The impression I have from discussion of bugs here is that Sony was using a newer version than Kobo had been using but, I don't think they are using RMSDK 10. Because each of the readers are probably using different builds of the RMSDK, if not different versions, then it is hard to compare the bugs between them and direct blame.

Before anyone jumps on me about this, it is Kobo's responsibility to fix the bugs in the firmware. But, because they rely on libraries and code from other sources, that can make it impossible to do quickly. If a bug is reported and Kobo discover it is in a library they get from elsewhere, they have to report it to that developer and wait for a fix. When they receive the fix they have to test the updated library. But, they don't just have to test the bug was fixed, they have to test all the rest of the function in the library that they use. That is a lot of work. So, they probably wait for a few bugs in the library to be fixed and do one round of testing for all of them. How long they wait would depend on the severity of the bug. A bug that makes the device reboot each time it was used, will be rolled out as soon as the fix is available (and has caused Kobo to withdraw an update). But, a bug such as "no hyphenation on the first line of a paragraph if the line is indented" is not going to make them take the risk and expense of an update to the library. Ten or twenty bugs like that might.

So, of course, Kobo go on developing new features. They can't fix the bugs that are out of their control. They do fix those that are in their control. And they add new features that they think are a "good idea".

[danwatto]

I've noticed 2 other bugs in the epub implementation after coming from Sony, related to the TOC:
1. Hierarchical TOC is not displayed correctly and is just shown as a flat TOC. This can be lived with.
2. Page numbers are not displayed next to the entries in the TOC. This is the worst, especially considering that epubs show the pages per book not pages per chapter. So there is no way of knowing how large chapters are or how long you have to keep reading until you reach a logical point of being able to put the book down..

Sony had these two things working perfectly, why does Kobo fail to read this information from the Epub?

Anyone know of any hack way to display this information (page number for chapter) on epubs?

[davidfor]

Originally Posted by danwatto

I've noticed 2 other bugs in the epub implementation after coming from Sony, related to the TOC:
1. Hierarchical TOC is not displayed correctly and is just shown as a flat TOC. This can be lived with.
2. Page numbers are not displayed next to the entries in the TOC. This is the worst, especially considering that epubs show the pages per book not pages per chapter. So there is no way of knowing how large chapters are or how long you have to keep reading until you reach a logical point of being able to put the book down..

Sony had these two things working perfectly, why does Kobo fail to read this information from the Epub?

Sorry, they are not bugs. Both are design choices that Kobo made. Why, I don't know. Personally, I don't care about the page numbers on the ToC, but I would like TOC hierarchy.

Anyone know of any hack way to display this information (page number for chapter) on epubs?

No, there isn't. The ToC is not built directly from the book when reading. When the book is first seen by the device, the metadata and ToC are extracted and stored in the database. When reading, the ToC is built from the database. The database does not contain the information for the page numbers. There is something that looks like it could be used for the hierarchy, but it isn't populated or used.

[norbusan]

Hi everyone,

it seems that 3.11.0 broke fonts on devices with Japanese UI and/or Japanese books.

What has changed is:

• Morisawa Ryumin and Gothic is replaced by A-OTF (see attached screenshots)
  In 3.8.0 there was Morisawa Ryumin and Gothic (see first screen shot), and now there is A-OTF Gothic MB101 Pr6N and A-OTF Ryumin Pr6N (see second screenshot). These are the same fonts, but they appear in different positions on the screen, and are not picked up as default font, with the effect that:
  • Document Default font cannot be displayed (see second screenshot, top of the list)
  • When opening a new book with "Document Default" font selected, nothing is shown
• Home screen has overlapping descriptions (see screenshot)

[anavin]

Originally Posted by norbusan

Hi everyone,

it seems that 3.11.0 broke fonts on devices with Japanese UI and/or Japanese books.

What has changed is:

• Morisawa Ryumin and Gothic is replaced by A-OTF (see attached screenshots)
  In 3.8.0 there was Morisawa Ryumin and Gothic (see first screen shot), and now there is A-OTF Gothic MB101 Pr6N and A-OTF Ryumin Pr6N (see second screenshot). These are the same fonts, but they appear in different positions on the screen, and are not picked up as default font, with the effect that:
  • Document Default font cannot be displayed (see second screenshot, top of the list)
  • When opening a new book with "Document Default" font selected, nothing is shown
• Home screen has overlapping descriptions (see screenshot)

I'd had this situation on my Glo once, too, when I upgraded from 3.2.0 to 3.11.0.
And then I tried factory-reset before upgrading; the situation didn't happen this time. So resetting the device might help.

(The problem is, my device continued freezing after 3.3.0 and I'd always downgraded my device to 3.2.0.)

[Anak]

Originally Posted by davidfor

Are any of these using the same version of the RMSDK as Kobo? Kobo is now using RMSDK 10, but not the latest build. Up until they upgraded to this earlier in the year they were using a very version that was at least two years old.

I didn't mentioned it as I took this (more or less) for granted that the same version of RMSDK must be used.
I don't argue that Kobo doesn't incorporate every single 'render engine' related bug (issue or improvement/add on) at once. That requires a lot of testing.

Originally Posted by norbusan

• Home screen has overlapping descriptions (see screenshot)

Well, this a good example of bug or error that is very easy to reproduce and therefore can - IMO: should be - avoided and fixed.
A similar issue is the cut off text in the reading stats if the device language is set to Dutch. The text string doesn't fit the allocated space.

The problem here is that the software engineer who is responsible for a specific firmware section must check the outcome for every single language. Double this if it is related to a rendering engine. Then both rendering engines have to be checked for for each language.

Note. There is no language barrier here. The software engineer doesn't have to detect translation errors or such. However he or she can check for text strings or items not being cut off or do not overlap.

If the engineer misses some of these easy to spot/reproduce mistakes/erors/bugs - and in real life it just happens - there should be a internal review process in place that tackles and fixes these kind of issues before the beta firmware is rolled out to a (external) beta testing group existing of knowledgable users. Reported bugs - for the sake of discussion limited here to those easy to spot/reproduce bugs/issues/errors/mistakes - should be fixed before the final release of the firmware version or - if it is more complicated to fix - with the next firmware release.
I could be wrong (actually I hope to be wrong) but I have the impression that the review part I described above is missing in Kobos firmware process or it has some serious flaws.

[filmo]

Adobe released Digital Editions 3 in January 2014.
https://www.mobileread.com/forums/sho...d.php?t=231939

[cybmole]

forgive my ignorance but is RMSDK not part of the firmware ? if not where does it reside & is it not upgradable ?

[zztush]

Originally Posted by norbusan

Hi everyone,

it seems that 3.11.0 broke fonts on devices with Japanese UI and/or Japanese books.

My Kobo Touch has no problem with Japanese fonts. I attached a screen shot.

[DNSB]

Originally Posted by cybmole

forgive my ignorance but is RMSDK not part of the firmware ? if not where does it reside & is it not upgradable ?

It is not part of Kobo's developed software. It is a library that is supplied by Adobe (in Kobo's case, I think it comes from Datalogics). It is upgradeable but any changes to it are going to require testing to ensure that fixing one bug has not broken something else -- of course, that never happens . If Kobo is doing the level of testing on RMSDK that I believe they should be, that testing is going to be quite time consuming.

[cybmole]

Originally Posted by DNSB

It is not part of Kobo's developed software. It is a library that is supplied by Adobe (in Kobo's case, I think it comes from Datalogics). It is upgradeable ...

that bit I knew; what I was asking is where is it on the device, is it within the firmware or in some other read only partition ?

and am I right in thinking that is is used only for interpreting epub, there's other code used only for handling kepub which does belong to Kobo ?

[shalym]

Originally Posted by DNSB

The epub renderer is Adobe's RMSDK. The main reason for it's existence is to support Adobe's ADEPT DRM so we can borrow/purchase DRMed epub ebooks. Adobe/Datalogics/whatever have been slowly moving towards epub3 compatibility. The release of RMSDK 11 has taken more steps in that direction through adding chunks of the Readium epub3 technology but RMSDK 11 is not yet available on Kobo's eInk readers. From what I've read, ADE 4.0 which has a similar code base to RMSDK 11 is best described as feature incomplete when it comes to epub3 support.

So I would characterize your belief that Kobo is slighting epub2 as being at best a paranoid fantasy.

I don't understand how Nooks and Sonys were ever able to read borrowed epubs, since they were somehow able to fix some of these issues. Or am I wrong about that? JSWolf, did your Sony have these same issues with epubs that are being reported here?

Shari