I see this more clearly now. I have long suspected it but actually working with the files and the editors confirms it for me. Hand held devices are fine for mostly black and white books with only a few images or diagrams. I'm reading Thomas Piketty's Capitol in the 21st Century now. Every night.
Picketty's diagrams work on the Kindle version but they're broken on the Playbooks version. I have another book "What the Robin Knows" where the opposite happens. On the bird book the sound files work for the Playbooks version but make no sound on the Kindle version. Bugs and formatting hassles like the above examples will get ironed out over time. I suspect bugs like the above have to do with varying ways of handling relative file paths in package.opf. Some opf files make resources relative to the OPS directory, some make them relative to directory that holds OPS.
But there is no solution to hand held memory limitations for books that are not mostly black and white text. For books that really do require pages of images, sound files AND most of all video there will have to be a server-side way to display epub files, so the images sound bytes and video are served in bits and pieces rather than all at once.
I remember in the early days of web pages developers figured out how to use simple javascript to display multiple images as a slideshow. But those first ugly attempts required the browser to download ALL the images first, before the slideshow started. Then they got smart and sent down a list of image URLs instead. Then the slideshow downloaded one by one, while the previous image was still showing. Now you can even leverage Ajax for asynchronous downloads.
Not all epubs have massive memory requirements. Some will. Some do. The phone app world will never support that functionality. We need a server side way to display epub, as well as a hand held device way. At least for how-to-do-it books that require giant memory.
Last edited by pittendrigh; 03-20-2018 at 01:49 PM.
|