Some serious issues with kepubs

[Anak]

Originally Posted by Sharkus

Probably us, ie; Kobo.

I think that when books are loaded onto the system there are some automated things that happen to the books, and I believe that adding the kobo css files is one of these things.

There were changes last year to the css, and books were being reprocessed. With the number of books we have, that can take some time.

Another thing to take into consideration is that any css changes do need to be evaluated on the various platforms to ensure they do not have unwanted behaviour. For example, a change that makes things better on eInk devices could cause a problem for an iOS device. I do recall iPhone and iPad css files, so there can be some device specific customizations, but anything generic we have to be very careful with.

Lets hope that Kobo drops the Linux Qt platform for coming new ereader devices and starts using Android as OS. I'm not saying that Android is better but as Android and iOS are the OS used on tablets it is the most logical step to reduce the number of platforms and (possible) rendering differences.

A good switch moment would be the release of a full epub 3 complient e-ink reader. Not just firmware wise but also hardware wise.
A full epub 3 complient reader needs at least have audio (speech) capabilities as this is a major part of the new epub 3 standard. I don't think I'll will use it myself very often but as multimedia is part of the new standard it should be capable to handle this.
Motion video will remain problematic as e-ink screens are different from LCD screens. But these hardware limitations don't apply to audio.

[taming]

Originally Posted by Anak

A full epub 3 complient reader needs at least have audio (speech) capabilities as this is a major part of the new epub 3 standard. I don't think I'll will use it myself very often but as multimedia is part of the new standard it should be capable to handle this.

Are you sure about this? My understanding is that the hardware on a device is not required to offer this (and various other things), but if a feature like this were to be offered, it had to follow the ePub3 conventions and epub3 can support them.

[Anak]

Originally Posted by taming

Are you sure about this? My understanding is that the hardware on a device is not required to offer this (and various other things), but if a feature like this were to be offered, it had to follow the ePub3 conventions and epub3 can support them.

Your interpretation of epub3 is correct.
But shouldn't Kobo add an audio feature to their devices as so many competitors already offer? Why not use the introduction/implementation of epub 3 to add an audio to it's devices.

[taming]

Their tablet and apps that run on other tablets could do this. I don't necessarily want or need it on my eInk device, but that is a matter of preference.

[buffaloseven]

Sorry, when I mentioned "they" I meant most ebook publishers in general. None of the ePubs I have do anything to distinguish images from other paragraphs.

And I'm not sure if moving to Android would work well; you'd need someone a little more knowledgeable but it seems to me part of the reason so many eReaders are using a variation of Linux is for the ability to optimize the OS for low-powered devices with relatively weak processors. I don't necessarily want them jamming a 2.4GHz processor into my eReader and having to add a 2 pound battery so the thing can run for more than a day.

[Sharkus]

Originally Posted by taming

Sharkus, if it is not a style sheet issue, but rather the coding of the book itself, then that is not a Kobo fix, but a Publisher issue though. Right? I have seen things that a style sheet fix will take care of, but other things that require some tweaking of the book's html.

Really depends on the exact problem. One other thing I forgot to mention, possibly specific only to iOS, is that we do have a javascript which is run and that applies certain changes to the css. A good example is the Kobo app for Rakuten (only in the Japan App Store), there were a lot of changes to our javascript to ensure correct rendering of Japanese text.

Here's a bit of the process when it comes to content issues (what we term issues with a book's rendering).

1. The issue is reported. Either directly to us, say from a feedback email, or from a ticket that has been filed by the team that looks at content.

2. We, typically myself, try and reproduce the issue. This is why I am known to ask for URL's to the books, different geo's can have different publishers for a book, and the content can be different, or same publisher but different content, for example, Harry Potter books come in a UK and US edition, and there are certain differences (trousers instead of pants).

3. If I find the issue, I then pass it along to one of the developers and ask them to check if this is a book issue or an app issue. If it is an app issue we will decide wether it is to be fixed or not. A bit elitist perhaps, but changes to the .js will require a round of content testing to ensure the "fix", a) works, b) does not break any other books. This is somewhat time consuming, and so we have to be sure it's something we really want to do. If this were an issue with a new bestseller, or a whole set of books from a specific publisher, then that gives weight to us fixing it.

If it's not an app issue, but an issue with the book content, depending on how we were informed about it, we'll respond to the ticket with details on the issue, and how it is caused and what, if anything, could be suggested to the publisher / author (it could be a self-pub book) on how to address the issue.

[Sharkus]

Originally Posted by taming

Their tablet and apps that run on other tablets could do this. I don't necessarily want or need it on my eInk device, but that is a matter of preference.

I could see how Aura could have audio functionality, the high end device side of things. But for the other eInk devices, not sure it'd be worth the inclusion.

Another factor is how much of this type of content is sold, and also what type is it? there are two I can think of, reflowable epub files with read-along audio, and fixed layout epubs with read-along audio.

The former might make sense for devices to include audio support, the latter, not sure something like "Big Bear Hug" would work too well on an eInk device (never tried it, so cannot truthfully comment), and so what's the point in spending time and money on implementing audio on eInk devices.

iOS certainly does support both of the audio types mentioned above, and has done since v5.5, released May 23rd 2012.

I don't see the eInk devices moving from their current setup, if you want a rich platform, then you would either use our iOS app on Apple's devices, or you would use our Android based devices (Vox, and Arc), or our Android app on other Android based devices. Why turn our eInk devices into a pseudo-tablet when we already have a tablet offering?

On a personal level, I don't use iOS or Android for reading. I do not need, nor want the overhead of a tablet / phone for reading a book. I have a Touch which at present is a perfect device for me, it's lightweight and dedicated to reading. I'm temped by an Aura, it's more a 'want' than a 'need' desire though, so I'm holding off for a bit. I could get a Glo, but if I'm going to upgrade, I want to get the best of the range and for me that'd be Aura.

[taming]

I also would be concerned about putting in the hardware to make audio work and the additional weight and cost (not just the hardware cost, but the cost on the development end for it to work). At $169, the cost of my Aura was about as high as I would be willing to go for an eInk device--especially since with the addition of a front light when the Glow was released, I really have not needed anything additional for plain old reading.

I have a big mobile (the Note2) and a fine 7 inch tablet (Nexus). My reader is for reading books.

[Quexos]

I got some issues with thumbnails. Whenever I rename an e-book from ...epub to ...kepub.epub the thumbnail in my device's library is gone and next to the name of the book there is a blank space where the thumbnail should be. I assume kepubs have their own code to display the thumbnail in the Kobo device or something like that. Anyone knows how I could get the thumbnail restored ? thanks

[taming]

I have not seen that when I have used the extended driver for epub to kepub conversion and loaded the books from calibre with that driver doing its thing.

[Quexos]

I just manually renamed an .epub to .kepub.epub as a test.
I assume your driver (whatever that is) corrects a few things inside the css or opf to make it work smoothly.
What is that driver you mention, some Calibre plugin or is it included in the basic calibre ?

Originally Posted by taming

I have not seen that when I have used the extended driver for epub to kepub conversion and loaded the books from calibre with that driver doing its thing.

[PeterT]

It's a calibre plugin; see [Device Plugin] Kobo Touch Extended Driver

[filmo]

My Sony T1 can play audio MP3 files it is feature seldom used because clumsy interface to change volume without dedicated switches and reduces battery time requiring charging sooner. Feature to read epub books with computer generated voice would be nice but would have same problems. T2 does not play MP3 files.

Do not want or need this on Kobo readers.

[DNSB]

Originally Posted by filmo

My Sony T1 can play audio MP3 files it is feature seldom used because clumsy interface to change volume without dedicated switches and reduces battery time requiring charging sooner. Feature to read epub books with computer generated voice would be nice but would have same problems. T2 does not play MP3 files.

Do not want or need this on Kobo readers.

The audio feature is so in demand that Amazon also dropped it from their later Kindles. The decision by most book publishers to mark their books as read aloud not permitted made the text to speech function pretty much useless.

Regards,
David