View Single Post
Old 02-16-2013, 04:09 AM   #16
kc7zzv
Member
kc7zzv began at the beginning.
 
Posts: 12
Karma: 10
Join Date: Jan 2009
Device: Handspring Palm
Quote:
Originally Posted by davidfor View Post
My apologies for pointing out an error in your post and explaining it. But, as it was the first time I referred to this in this thread, I think "Belabouring this point", is a bit much.

Now if you had accused me of being pedantic in my explanation, then I will plead guilty. I was trying to make sure you understood what was going on. The only issue with the "close enough" is that Kobo might decide this is a bug (reading a epub 3 attribute in an epub 2 file) and fix it.
At least twice I've said that "I think Kobo might do X non-standards conforming thing, but it's close enough to being a normal epub that I won't worry about it." This was about the cover piece, and mis-remembering that the Kobo uses a custom attribute in the span.

My point has been that using the epub input code will work fine. I will do more investigation before I start programming in earnest. I understand that you want to help keep me technically accurate, but correcting me on things which are not going to be technical problems, and that aren't likely to actually be implemented in the broken way I stated does nothing except derail this discussion.

I'm sorry I snapped at you, but I was only trying to state the worst case that I remembered might be true, as a way of "padding my estimates".

Basically, if I say, "Even if X is true, we should still be fine," please don't correct me to tell me X is false, unless you think that's something I could somehow miss later.


Quote:
Originally Posted by davidfor View Post
But, to belabour a point before I continue. I think that having calibre capable of putting properly formatted kepubs on the Kobo devices is a good idea. But, I am not convinced that having kepub as a format inside calibre is very useful. And I think don't think it is more useful than the driver method.
Actually, I had found the plugin, and I learned it existed, but I think I got it confused with an older branch. I've been testing it, and been happy to find that it does much of what I wanted, and more than I expected.


Quote:
Originally Posted by davidfor View Post
I am not trying to convince you that splitting a epub or kepub into smaller chunks won't be faster when turning the page. I am fairly sure that it will be. But there is a minimum size that makes it slower as going from one file in the epub/kepub to another is slower.

From what I see for performance and usability, the best split is at chapter marks [pedantic me: where it says "Chapter x" or "Part x" or just "x"]. It is rare to find a book that has chapters large enough to want to split them into smaller files. But, it is common to find epubs that have not been split at chapters.
I have an epub (not kepub) generated by Calibre, where Calibre didn't find the chapter marks. (This isn't really Calibre's fault, since even a human would have had a hard time) It contains 653k characters, and 7.9k lines. Aside from the header and footer, half the lines are a single "br" tag, and the other half are lines of text beginning and ending with a "p" tag.

The file contains literally no formatting, tags or css, and no links to external css. Near the end of the book, turning the page takes 2-5 seconds near the beginning of the book (I didn't time this) but over 15 seconds near the end of the book. (I timed this)

You might argue that this is a bug in the kobo, and/or this would be fixed if the book had proper chapter marks. I agree with both of those statements, but I consider them tangent to my point.

I think this means that books of this size should have been automatically split by Calibre into smaller pieces before being sent to my Kobo. Since 700KB in size was way too long, I'm planning to try splitting at 25KB, 75KB, 100KB, 150KB, and 250KB. I'm hoping that a default of 100KB will be a "small enough" default piece to fix this problem, and large enough that users won't get annoyed at "too many" page breaks. Then I want to test what effect using Kepubs has on the speed with the diffierent sizes. (I'll be testing this as soon as I manage to get my Kobo working, since this file seems to have caused it to hang.)

Quote:
Originally Posted by davidfor View Post
Why one earth would you do that? It is not needed on any of the Kobo devices to split the text into "tiny pieces". Or do we disagree on the how big "tiny" is? And if you read my posts, I am a big advocate of splitting at chapter breaks. That will not put page-breaks in ugly places.
I think this was a miscommunication. To me, "tiny pieces" is somewhere between 100KB and 20KB depending on testing.

Quote:
Originally Posted by davidfor View Post
Huh? Of course all that is the case. Why would you do any of that if the size is a big concern to you. The spans and ids have nothing to do with other readers (that was the point I was asking about) as they are only added to kepubs. Same with the kepub specific javascript. But I don't understand how this affects other readers as kepubs don't go onto them.
I think there was some confusion here. I only said that I don't want to add the Kobo Javascript to, or split the epubbs in my library. I have no objections doing that to kepubs, or epubs that will only be on my Kobo.

Firstly, I won't correct you because I think "kepub reader" is a perfectly good description. I do use "kepub renderer" in some places, but that is because it fits the discussion.


Quote:
Originally Posted by davidfor View Post
Sorry, but calibre does work very well with the Kobo device out of the box with no configuration changes. Any changes people make are because they want to fine tune it. The issues you are talking about are related to the structure of the books being read or maybe some firmware bugs.
If you believe this, then either you are pretty lucky, or I'm very unlucky, because I've used several ebooks that all took over 5 seconds per page turn.
kc7zzv is offline   Reply With Quote