Mobileread
v0.1.2 very slow when editing on Mac
#11  Valloric 08-18-2009, 01:02 PM
Quote Dave Berk
What other option is there?
A poll/discussion thread on the future direction of Sigil's development (with this issue central) is forthcoming. Watch the forum.
Reply 

#12  kovidgoyal 08-18-2009, 01:28 PM
My vote would be to split files over a certain size and use split files if they already exist.
Reply 

#13  Xenophon 08-18-2009, 06:06 PM
Quote Valloric
It does. It most certainly does.

It just that Sigil is not the problem. The epub file is. The markup is... horrible, to say the least. For instance, every paragraph with text starts like this:
Code
<p onmouseover="PNo(1032)">
And there is no javascript included in the book, from what I can tell. This only serves to slow down browsers. Also, between every two paragraphs with text there is code like this:
Code
<p><a id="p1033" name="p1033"/></p>
Which does God knows what.

And I see what you mean when you said the text was centered. I thought you meant fully justified, but no, it is really centered. Removing the CSS style that applies "text-align: center" fixed this.

With that CSS style gone, and after removing all the useless "p/anchors" and the onmouseover handlers with some regexes in notepad++, your file now takes up 30MB less memory and can be nicely edited in Sigil with no lag. So CPU usage solved.

The memory consumption is still around 100MB, but your file is 80k XHTML lines-of-code. It is 1.4MB as an epub because epubs are compressed ZIP archives, and plain text gets compressed nicely. In Sigil, text is in uncompressed UTF-16 which means at least two bytes for every character, whereas your file is English in UTF-8, so only one byte per character stored. This effectively doubles the memory required to store your text in Sigil.

Now take into account that because of technical limitations of Qt widgets used for Code View and Book View, there are three text buffers instead of one, and that Book View is an embedded web browser... these things add up.

In the end it was your file that was causing the lag. Must have been an old version of calibre they were using when they created it, because that's some really painful markup.
I recognize those HTML parts! If you visit the Baen free library (for example) and read a book there on the Web -- that is, you view in your browser rather than downloading and reading locally -- you get html that contains these parts. What they appear to be is support for identifying paragraphs by number (those are paragraphs #1032 and #1033 in your quoted examples above). That was useful stuff when users were reporting typos and other bugs to the publisher from the Web, but serve no purpose in a downloaded eBook.

Kovid built the -Baen preprocessing switch for Calibre exactly to strip that stuff out (at my request). May I suggest that Sigil provide the same capability? It's a straight-forward bit of sed script hacking...

Xenophon

P.S. I'll poke Baen's web guy about removing that cruft from his eBook versions.
Reply 

#14  Valloric 08-18-2009, 06:27 PM
Quote Xenophon
Kovid built the -Baen preprocessing switch for Calibre exactly to strip that stuff out (at my request). May I suggest that Sigil provide the same capability? It's a straight-forward bit of sed script hacking...
Sigil is an editor, and as such it strives to present the epub you loaded as faithfully as possible. When the search&replace dialog is done, it will be very easy to remove these directly. But Sigil will not remove them for you automatically. Maybe as an option in some pop-up import dialog. Maybe.

Until then (and after too, for those who want to) just run it through calibre to remove these. There's little point in duplicating functionality.

Quote Xenophon
P.S. I'll poke Baen's web guy about removing that cruft from his eBook versions.
Please do that. It would benefit all readers of those books, since it would speed up display and lower memory consumption on all Reading Systems.
Reply 

 « First  « Prev   (2/2)
Today's Posts | Search this Thread | Login | Register