[geek1011]

Overall, I feel the Kobos have more pros than cons. I would always choose a Kobo over basically any other brand.

Originally Posted by John F

Did you read the title of my first post? The firmware works very well for how I use it. It is the best, for how I use it. It doesn't suck, and it isn't perfect.

I agree with this completely. Also, I prefer Kobo hardware over Kindle as well (in general).

Originally Posted by rashkae

Kobo, on the other hand, routinely introduces new bugs, and often times, they are there for what feels like a year and over 6 firmware releases before they are fixed. (I could cite examples, but I would only be venting my own pet peeves.)

I also wish there was a bit more structure to the releases, as there are sometimes hours and sometimes months between releases. Also, I still can't figure out for the life of me what that '-s' version was all about. Also, the thing which happens every now and then with them releasing a buggy version, then a new one shortly after (just after I finish the patches) bothers me a bit.

Originally Posted by rashkae

1. I'll start with the issue that started this thread even. Adjustment of text selection with the 'handles.' Once text is selected, the selection can not be adjusted unless you know the trick to moving the handles. (drag once to 'unlock' them, then once the pop up menu is gone, drag again to actually move.) This was a regression added in an update at least 3 versions ago.

Once I got used to that, I actually liked it better, as I'm not constantly trying to see under my finger when I start dragging. It also helps because the touchscreen is a bit offset for me (that's my number one bug), so I can properly estimate the offset I need.

2. New regression affecting Epub files introduced with 4.15. In some books, if there are two TOC entries pointing to the the same internal file, (ex: Heading and subheading,), at some points in the book, putting the kobo to sleep or going back to home will loose your current page. Bookmarks and highlights are also impossible to create in these locations.

That is a bit of a issue, but I am not going to complain about that. Keeping track of position is one of the most complicated things to do with EPUBs. The standard seems to be CFIs, but every implementation is buggy (including my own attempts at them).

Originally Posted by Lucas Malor

3. the virtual keyboard is highly unresponsive. it takes seconds to display the touched character

I think that's more of a hardware issue (but I'm not 100% certain). It feels instant on my Kobo Mini which uses the infrared touchscreen, but I agree with the lag on my Aura Edition 2.

when I have the bad idea to read a pdf, I usually turn it 90 degrees and I zoom it a little, so I can read them better. The problem is that, when I reach the end of the page and I touch to change page, the next page is displayed at the same level of the previous page, ie the bottom...

I'm not entirely sure what you mean by that (I don't read too many PDFs), but if you mean that you want the pan/zoom position preserved between pages, there's a patch for that (it was missing for a while, but I redid it a month or two ago).

5. sometimes, if I connect the Kobo to the pc and I edit a text file, like the nightmode ini, when I safely disconnect the device, it look like is completely reset. No books, nothing. I have to restart to restore the normal situation, after some heart attack and some profanity.

There are many possible causes for this. Does your Kobo ever disconnect randomly (I have that issue intermittently)?

Originally Posted by Sarmat89

That's not stupidity. EPUB format is too complex to be parsed and rendered by an embedded device, so it must be preprocessed into a less taxing form, like predictable-structure kepub or lightweight binary KFX.

I disagree that the EPUB format is too complex to be parsed and rendered by an embedded device, but agree it is complex in general. The part about the kepubs does not make it any less taxing, but it makes many things simpler to implement. I'm not sure whether I'd call KFX lightweight or simple though. Structured, maybe, but not simple.

Originally Posted by DNSB

HUH???? Kepub is epub format with added spans making the kepub structure, if anything, more complex than epub structure. So all these years I thought I was using RMSDK or ACCESS on my Kobo ereaders to parse and render epub2 and epub3 files never happened?

Technically, you're correct about the spans making it more complex, but it really makes things simpler in every way which matters. If all EPUBs had those spans, developing tools for working with EPUBs would be way simpler. Those spans mean that there is a consistent way to track the position of bits of text in books without resorting to the other common methods: CFIs (which are extremely difficult to parse correctly), scroll percentage (which is not consistent between readers, and is lossy), word/character number (which doesn't work with books mainly composing of images, and what about hidden stuff), and display page (which is not consistent between font sizes, screen sizes, and so on). With those spans, all you need to do is find the first and last one visible for the range you need. Also, since in general, the spans don't contain other elements, it is easier to get a specific piece of the document without any ambiguity.

Originally Posted by FrustratedReader

So the differences of epub and kepub are some mysterious idea to suit Kobo, nothing to do with cpu / RAM load of parsing.

It's just about simplicity for development and consistency between devices.

Originally Posted by FrustratedReader

No I did not. Since I have actually WRITTEN interpreters and and compiler I'm familiar with the concepts. However it's NOT the same idea at all as p-code or bytecode as that is a program executed on a virtual machine. The KFX is a compression of DATA, it's mostly content. Text & Images. Even the styling information originating in CSS isn't instructions in the the bytecode / pcode sense. The KFX is really entirely specifying data like a Word 95 doc file, it's not instructions in the sense of VB, or Java program.

...

Like bytecode/p-code to Java, J++, C#, VB or UCSD-Pascal, you can get back a human readable source, but it will have lost all non-essential to the page content and rendering information and be hard to read.

Yep. That's correct.