Quote:
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.
Quote:
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.
— — —