Faster loading of EPUBs in viewer?

[democrite]

Hello,

Often I make EPUBs from scans. As I'm editing, making corrections, etc., I return to the viewer to reload the EPUB. It would be nice if it were possible to load quicker. If the file hasn't changed since last load, it is pretty quick. It would be great if first loading of EPUB or after it's been edited were as fast. I think there are ZIP libraries that can unzip to memory. Would it be possible to load first into RAM and then create the cache and do other necessary stuff as a thread so that initial load and so forth is as fast as possible? Maybe it'd be a bit of work though I think it'd greatly enhance the experience. ADE for example can read and display an EPUB in less than a second.

[FizzyWater]

Which version of Calibre are you using? The speed of opening the viewer has improved since 4.0.

[kovidgoyal]

It's not going to be faster than it is in 4.3, why are you reloading the book in the viewer anyway? the editor has a perfectly good preview panel precisely so you dont have to reload the book to see how your changes look.

[theducks]

Preview PANE
I don't ever remember seeing a VISUAL difference.
The Viewer allows USER modification, which is NOT desirable during initial formatting (Just the codes way).

[democrite]

Originally Posted by kovidgoyal

It's not going to be faster than it is in 4.3 …

Perhaps you mean there is little interest in trying to make it faster. Potentially I'm not sure what is as fast as possible. Maybe reading the EPUB into RAM with an appropriate ZIP library, parsing as little as possible first to display a page, whether first or last read, and everything else do in the background while perhaps having some UI elements not enabled until ready. The measurement and I think ideal goal of (impossible) possible load speed is like that of text documents or PDFs, instant.

Originally Posted by kovidgoyal

… why are you reloading the book in the viewer anyway? the editor has a perfectly good preview panel precisely so you dont have to reload the book to see how your changes look.

Imagine all the possible scenarios when one might want to reload an EPUB. I am not always using an editor. In my case, I tend to make EPUBs only of works that are difficult to proof. An example, as brahmins, rishis, etc., that is certain kinds of people, have little interest except in vedas, shastras, etc., works of the highest knowledge, I tend to scan and make EPUBs of works that are dual language of ancient texts that need effort to proof, e.g., transliterated Sanskrit or some other ancient language. That requires having side by side the PDF and the viewer set as such so line breaks somewhat match and I can side by side compare.

To make such work as efficient as possible, if I want to make a change, I highlight some text then press one key to run an AppleScript to search and highlight the text in an editor that supports AppleScript. After the change, another key switches back to the viewer and reloads the EPUB. Maybe something faster is possible; I will try to reduce any mouse movements and keystrokes to as minimum as possible. There are other cases when I'm not necessarily working on the EPUB itself; I may be just reading and notice some typo. Quickest way is to again run some AppleScript to globally search the file for such text. Not everyone is going to always be in the editor or using the calibre editor.

Having the app as refined as possible, with this as an example, would be nice. It seems possible; perhaps you will keep it in mind and maybe someday decide to make such changes.

[DoctorOhh]

Originally Posted by democrite

Perhaps you mean there is little interest in trying to make it faster.

Since he is the creator/programer of this program and has spent the last three versions optimizing the speed of opening a new epub I think it is safe to assume he is saying exactly what he means. He is finished optimizing the opening of first read epubs, thus "It's not going to be faster than it is in 4.3"

But maybe your argument will persuade him to try once more or possibly divine inspiration may guide his hand. You never know.

[democrite]

Maybe most tend to not often modify their books, and as such don’t mind the creation of cache and so forth that happens only once per book. For me, with commercial EPUBs too I often fix formatting and typos not necessarily all at once in an editor, but whenever I find them as I read. An example, one I haven’t looked at in a while but am getting back to, a work not well proofed and not well made, hundreds of unique typos, many in transliterated Sanskrit. Finding them is constant, and each time a reload recreates the cache and takes 8+ seconds due to images. Not fun.

[sjfan]

Originally Posted by kovidgoyal

It's not going to be faster than it is in 4.3, why are you reloading the book in the viewer anyway? the editor has a perfectly good preview panel precisely so you dont have to reload the book to see how your changes look.

Lots of authoring flows don't use a GUI editor. Many of my ebooks are dynamically built from database sources and templates, and not edited directly in ebook-edit or Sigil or the like; after rebuilding the book, it's opened in various viewers to proof the new changes. The speed improvements you made in 4.3 were hugely useful for this kind of flow!