Quote:
Originally Posted by davidfor
No, you haven't misunderstood. The KoboExtendedTouch will do an on-the-fly conversion when you send the books. But, in this particular case, I just renamed the file. Changing the extension to ".kepub.epub" is enough for it to be treated as a kepub. And for a one or two page test case, or to do a quick check, it works well. But, if you are reading a book, you need the conversion so that the reading position and bookmarks are maintained properly.
I would expect that to trigger the bug. The problem, I believe, is that when you first open a kepub, it does a word count for each ToC entry and stores it in the database. This is used as you read for the chapter graph in the in-book stats (my favourite thing about kepubs). But, this takes time and the bigger the ToC, the longer. But, there is a process watcher called sickel that will trigger a reboot if a process appears to be hung. What I believe is happening is that the word counting is taking to long and sickel triggers a reboot. For all my test cases, when I try to open the book again, it work. So I think that in the first attempt, enough of the counts have been done and stored that on the next attempt it finishes and the book opens.
I would suggest creating a smaller sample book with only a couple of chapters so you can see what it looks like.
It's been a long time since I tried a HTML file, so I just tried a couple. Firstly, they don't seem to like links to local other files. I tried a few things and none worked. A link to a web page will prompt you to open it in the browser. Not sure about the CSS. Other parts of the display suggest the HTML file is displayed using the kepub renderer. If so, it might only use the CSS that the kepub does. But, I'm surprised that anything you had in an epub didn't work here.
I always recommend reporting bugs and problems to the people responsible for them. There is link on Kobo's help page to report problems. As to how likely something is to happen, it really depends on how it fits with what they are doing. Some things get fixed quickly, others take a long time. But, if they don't know it's a problem for their users, they won't do anything.
|
I eventually found the time to run the test your last message implied…
1. I created a much smaller epub with the first of my html files. The toc.ncx and content.opf files were modified to reflect the change. Activated the "Kobo extended" plugin and transferred the book to the Kobo. I was able to open the converted book on the device.
2. I added the next four .html files from my original book, which entailed adding perhaps another twenty toc.ncx entries. I was again able to open the book… and I noticed that it was taking rather long… I also noticed that my nested ToC was there all right… complete with my second & third level entries… But since Kobo do not support nested tables of contents it had been "flattened" so-to-speak…
3. I proceeded to run a third test adding another five chapters from my book… This meant adding another 200+ entries to the ToC… This particular test version was now about one third of my original book and this sufficed to "successfully" recreate the problem: the Kobo crashed every time I tried to open the book… I did that maybe five times in all and consistently got the same result.
So it would appear that at least where sideloaded epub's as converted to kepub.epub by the "Kobo extended" plugin… Kobo's current software does not scale properly and cannot handle a table of contents with more than a few entries.
Apart from the fact that nested tables of contents are not supported… which makes large ones such as this particular book's all but useless--who wants to look for something sequentially in a ToC that spreads over a hundred pages especially on a device as slow as the Kobo Glo' I ask you… the fact that where kepub's and "raw" html are concerned, Kobo's e-reading software is unable to handle correctly titles that are marked "text-align:center"… I noticed another annoyance: I use em's to specify font-sizes and I rarely go beyond anything fancier than 1.3em… anything larger takes up too much space and looks rather gross to my sensitive eyes. And yet with this particular rendering software (as I roughly measured it) the font height and font width double in size when I go from 1em to 1.3em… whichever font I decide to use… This btw reminds me of something that I had noticed before on the sole book I ever bought from the Kobo store: titles that were unusually large giving the book the aspect of the ads on some cheap commercial internet site… something that I also notice on web pages as rendered in Google Chrome…
Well… considering that I don't feel it is worth having to jump through so many hoops hoping to miraculously get this to work… kind of… eventually… and find myself not happy with the result anyway… I'll put this on the back burner for the foreseeable future… perhaps have another look in 10 years' time… in case the situation has improved.
In any case… where I am concerned… this wasn't a waste of time… far from it… I now have a text version of the book almost ready to roll… and perhaps more importantly… the refresher course was worth every hour I spent… I try to "do an epub" once in a while so I don't forget my feeble epub skills for good.
Enough moaning and whining for now…
Thanks to all for your patience…