Is there a way to "push" a book to a Kobo reader wirelessly?

[mramosch]

The thing is that Javascript actually IS supported. You can execute JS on page load. So it can’t be a security concern issue!

The only missing part here is that touches get absorbed by the reader app for accessing the menu.

On iOS you can use event.preventDefault() to break through this filter and get to your underlying JS code for providing the user with further interactive functionality.

Only on the KOBO device itself you can’t…

[Aleron Ives]

That's pretty odd. I guess it really is just a case of "too lazy to implement the spec" at work here.

[DNSB]

For my purposes, the limited implementation of JS in the Kobo WebKit based renderer is moderately useful but 99.99% of the ebooks I've seen do not use JS at all. I also remember that Kobo's ereaders are intended for reading ebooks. Most of the features of JS are less than useless for reading ebooks. Implementing features that would not be useful for ebooks is not laziness, it's more likely that the programmers are trying to keep the code size down for a device with limited memory and CPU.

Originally Posted by mramosch

On iOS you can use event.preventDefault() to break through this filter and get to your underlying JS code for providing the user with further interactive functionality.
Only on the KOBO device itself you can’t…

I am curious as to what layer below the renderer on a Kobo ereader are you trying to send touch events to? The Linux OS? Have you written a shim to run between the renderer and Linux?

[mramosch]

Originally Posted by DNSB

I am curious as to what layer below the renderer on a Kobo ereader are you trying to send touch events to? The Linux OS? Have you written a shim to run between the renderer and Linux?

Sorry, I may have not expressed myself very clearly. I am only referring to the Javascript code in the epub itself. But I consider the touch interface of the device as a layer that gets ‘hijacked’ by the application developer to facilitate all the functionality for navigating the book. A simple implementation just lets you decide where to tap or swipe to turn pages. A more advanced implementation like in BookFusion lets you divide your screen into a 3x3 grid and you can de-/activate page turn for every tile, which means you can hold your eReader like a real book by having your fingers on the screen without accidentally opening the navigation menus if you e.g only activate one tile in the top-left corner of the screen.

So apps like AppleBooks, BookFusion or FileBrowser let the touches fall through their ‘hijacked’ layer and hence giving the epub developer/publisher the opportunity to add further interactivity to their content.

Originally Posted by DNSB

For my purposes, the limited implementation of JS in the Kobo WebKit based renderer is moderately useful but 99.99% of the ebooks I've seen do not use JS at all. I also remember that Kobo's ereaders are intended for reading ebooks. Most of the features of JS are less than useless for reading ebooks. Implementing features that would not be useful for ebooks is not laziness, it's more likely that the programmers are trying to keep the code size down for a device with limited memory and CPU.

Well, I can tell you a few very useful things that my implementation of JS in an ebook facilitates with a couple of bytes only.

If one insists on using a device for reading text only and not for listening to audiobooks you might - e.g. for language acquisition purposes - nevertheless enjoy features for accessing multi-lingual content on demand without using the clumsy interface of most reader applications and without having to get your device’s battery drained because you need WiFi to connect to translation servers. The lack of complete implementations of the epub3 standard and proprietary decisions on many readers give us producers headaches with pop-ups, links, footnotes, endnotes etc. - we all know this from other threads ;-)

That’s where a few lines of JS can come in very handy.

And if you you are willing to leave the ‘reading only’ reservation the same holds true for some audio magic.

I managed to find a way to make epubs with MediaOverlays also accessible on apps like Apple Books although they are all trying hard to convince us that you need their KOBO, Apple, Amazon like Audible-Stores to be able to consume AudioBooks on their proprietary platforms.

In addition you can have AudioBooks be much more accessible (and here I am literally talking about ‘Accessibility’ for the handicapped/impaired folks - I hope I am being politically correct here with these expressions) than they are with the standard transport bar interfaces.

Now that I have all this working on non e-Ink screen devices I wanna have the same functionality on e-Ink, that’s my dream for consuming multilingual text and AudioBooks.


I hope that answers your questions.

— — —

[HLS]

Is there a reason that you just don't buy the ebooks from KOBO store? it is illegal to strip DRM off of ebooks

[mramosch]

DELETED: misunderstood the question…

[Quoth]

Originally Posted by HLS

Is there a reason that you just don't buy the ebooks from KOBO store? it is illegal to strip DRM off of ebooks

No, in most countries it's illegal to break copyright by distributing free or paid copies and the rights owner has to sue. They'd have to sue for breach of contact in most countries for DRM removal and the penalty is limited in most countries to the losses. If it's only personal use, there are no losses to the rights holder.

There is a load of FUD about DRM, that's propagated by large US companies wanting to control the consumer. It's not about piracy.
Even the DMCA is only the USA and might not even apply. The "injured" rights holder would have to prove a loss.

[John F]

Originally Posted by Quoth

No, in most countries it's illegal to break copyright by distributing free or paid copies and the rights owner has to sue. They'd have to sue for breach of contact in most countries for DRM removal and the penalty is limited in most countries to the losses. If it's only personal use, there are no losses to the rights holder.

...

Maybe, maybe not.

[Aleron Ives]

Originally Posted by DNSB

Implementing features that would not be useful for ebooks is not laziness, it's more likely that the programmers are trying to keep the code size down for a device with limited memory and CPU.

Does the EPUB3 spec not define what a reading platform should be able to do with JS?

[PeterT]

For what it's worth here are the ePub 3.3 compliance testing results --> https://w3c.github.io/epub-tests/results

It's not stated how exactly the testing is performed for Kobo, but I thin k it's safe to say it will be with kepub format through (what was once) the Net Access engine (I don't recall it's current name).

[Aleron Ives]

Yeah, Kobo uses an old version of RMSDK that doesn't support EPUB3. Firmware 4.x uses WebKit for KEPUB, but I recall somebody said that firmware 5.x may have an updated engine.

Section 3.10 seems to say that scripting support is optional, so I guess DNSB would be correct that Kobo can ignore some or all of the functionality as the developers see fit while still claiming EPUB3 support in general.

[DNSB]

Originally Posted by mramosch

Too long. Didn't quote...
— — —

The problem for me is that I read at about 1,000 WPM. Any audio book playback is at a far lower speed or totally undecipherable by my ears. As for mentioning things like listening to books while driving? I really don't need to get nicked for distracted driving.

As for using the types of books you seem to want Kobo to support despite the hardware limitations? I have my desktop computer, laptop computer, iPad Pro and Lenovo M8 tablet for when I want to scratch those itches. Yes, 3/4 of them were more expensive than my Sage but sometimes, you need an i9-24 core with 64GB of memory and 4TB of PCI4 SSD storage to keep yourself from dying from impatience. I worked in IT for decades and needed my toys to do much of my work and have seen little reason not to continue keeping them up to date.

I read books in English mostly with the occasional French, German and Spanish book where the language to English dictionaries tend to get a good workout.

If I want to translate a book, I use the Ebook Translator plugin in calibre and let my desktop do the heavy lifting. Similarly I use a calibre plugin for converting an ebook to audio. Every once in a while, I give audiobooks another try. So far nothing but cold pancakes and no honey.

As for interactive ebooks? They've been pushed at least since Ted Nelson in the 1960s. So far, any efforts that I've seen have convinced me that interactive books are little more than a solution in search of a problem.

Media overlays? The last interactive book project I was involved with was a ebook with media overlays ended up foundering on the sheer size of the book. 2MB for the original books, 307MB for the media overlay version in development—those images and audio files chewed up space like it was free. The project was eventually dumped though they had the sense to stop the project while they could still pay out the contractors (my personal opinion as one of those contractors). There may have been a few fans who would have purchased the ebook regardless of size and cost but not enough to make it financially viable considering that it had issues with Amazon's requirements so would miss out on the elephant in the ebook market.

[DNSB]

Originally Posted by Aleron Ives

Does the EPUB3 spec not define what a reading platform should be able to do with JS?

If you consider optional to be a directive, yes. Very little is labelled as MUST with MAY being seen all too often. If you want to play with hasFeature, be prepared to be disappointed. You can also take a look at GooglePlay which is listed as ePub3 compatible but has no Javascript support. I really recommend the ePub 3.3 specification as an insomnia cure.

Looking at the rather aged Kobo epub spec page:

Kobo’s Android and iOS platforms support JavaScript for Fixed Layout and reflowable ePubs, but it is recommended not to use JavaScript in reflowable content in ways that may alter the layout of the book. Any EPUBs that depend on JavaScript functionality to present readable content will not pass content QA.

Kobo’s eInk and Desktop platforms have limited support for JavaScript, and do not support interactive JavaScript elements.