[davidfor]

Originally Posted by kc7zzv

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."

Good, I am glad you realise that. I never said in any way that that wasn't the case. In fact, if you have a look at my posting history on this forum, you will find me explaining exactly that far too many times.

This was about the cover piece, and mis-remembering that the Kobo uses a custom attribute in the span.

Well, to be precise, you made a reference to "non-conforming part that I know of is extra attributes in the span tags". I pointed out that it was valid code in an epub. You then stated that you remembered wrong and that it was a "custom attribute" in the metadata. At that point I knew what you were talking about, so I explained my understanding of that.

My apologies for explaining something that I happened to have done some research on in the past. And also my apologies for correcting some terminology in the attempt to make sure we were all talking about the same thing.

My point has been that using the epub input code will work fine.

When have I said that wasn't going to be the case? The conversion code from epub to kepub is going to be a doddle. Especially with examples of how to add the spans that are already around. And the conversion the other way is basically just renaming the file.

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.

What do you think I was doing? I am not answering your posts or picking on you for sport. I was reading what you were saying and trying to understand it. I found what I considered to be errors, so I commented on them. I found things that seemed to be lack of understanding, so I commented on them. I saw some statements from you that seemed to be contradicting each other, so I commented on them to try and sort it out. I also wasn't sure I understood somethings, so I asked about those.

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.

I have done plenty of conversions where calibre didn't pick up the chapters. Generally I use Sigil to fix this afterwards.

To get a 653KB file in an epub after a conversion, you had to make a change to the conversion settings. The default split size on the 260KB. Try redoing the conversion but make sure the split size is the default or smaller.

What do you mean by "header" and "footers"? They don't makes sense in an epub. Was this a conversion from a PDF that had headers and footers that weren't removed?

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.)

OK, with times like that, I can understand you wanting to look at it. But, as Kovid said, size isn't the real factor. Complexity of code is.

To explain this, I mentioned a epub I have earlier. This is one I constructed specifically to test some size related questions someone else had. The book has about 30 chapters. The original version had each chapter in a separate file between 10KB and 50KB in size. Plus there were three small files for cover and other non-story things. I combine the chapters into three files that were 342KB, 296KB and 739KB in size. They are in that order in the file. When I uses this before, I was testing battery life, and didn't pay attention to page turning speed. But, I put it back on and did some quick tests.

At the beginning of the book the page turning is sub-second. At the end of the first file, it is slower, but still sub-second. At the beginning of both the other files, it is fast. The only real noticeable speed drop is at the end of the third file, the 739KB file. And then it is maybe three seconds. No were near as bad you are seeing with smaller file sizes.

The difference is that the code in this book is clean. There are no extra tags for weird things. CSS is used to handle everything nicely. The epub you are describing is badly formatted. This will cause performance problems. Cleaning this up will help a lot more that splitting the files up. But, splitting on chapters (when calibre can detect them) and using the default split size (mainly for when the chapter detection fails) will usually result in reasonable performance.

For curiosity, I also put the book on as a kepub. It didn't have the extra spans, but that shouldn't affect the performance much. Page turning on it was sub-second throughout the book.

I would be interested to see this book you are having trouble with. It would be interesting to see exactly what sort of code in the book caused this as I have never seen performance as bad as you describe. If you are willing to send it to me, send a PM with a place I can get it, or I can send email address.

As to determining an optimum split size, which device are you going to use? Touch, Glo or Mini? Or maybe the original Kobo or Kobo WiFi? And which firmware version? The performance is different on all these devices and the different firmware has had a lot of effect on performance as well.

I think this was a miscommunication. To me, "tiny pieces" is somewhere between 100KB and 20KB depending on testing.

Yes, that is a miscommunication. I was thinking two or three pages. 100KB is a novella and 20KB is 20 or 30 pages. I usually see split files shorter than that as a 20 page chapter is on the long side. Or did you mean 200KB?

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.

My comment about calibre working well out of the box was related to how much configuration you stated was needed. All of those configuration items are personal desires. Calibre handles the Kobo devices very well without doing any of these.

The performance of books on the Kobo device is a different matter. These books would behave like that if you put them on without using calibre.