[GUI Plugin] Modify ePub

[theducks]

Originally Posted by BetterRed

You can select an arbitrary number of saved searches in the 'usual' way (ctrl+left mouse button click) and execute them - Find/Replace/Replace All.

I don't think there's a way to save the multi item selection so you can reuse.

BR

I just gleaned this.
The simple difference between Calibre and Sigils way, is you could run the group in Sigil.

The (chain) Order in which replaces are done can be important in many cases. Does the selection list ALWAYS run from top to bottom?

[kovidgoyal]

You can re-order the entries in that list and filter them by any string, which means the functionality is a strict superset of groups. It is less discoverable than groups however.

[Divingduck]

Originally Posted by Rev. Bob

Could you expand on that a bit?

As Kovid and BetterRed already answered thats the way I do it. In addition I collect similar S&R definitions together and export/import it as S&R sets. This give me the opportunity to have a more or less clean set of actions available what can be used when ever I need a suitable set for S&R.

Edit:
Maybe this pic will give you aa example how I use S&R with the editor

[Francois_C]

Originally Posted by theducks

I also use a unique, class for clarity when it encompasses the whole paragraph,

<p class="foo">Stuff</p>

instead of

<p class="foo"><span class="bold"><span class=:big">Stuff</span></span></p>

Bigger CSS, but smaller TEXT section files

I often redefine <p> this way:

p {font-size:1em;text-align:justify;text-indent:0;margin:0 0 0 0}
p + p {text-indent:1em}

and replace all occurrences of:

<p class="foo"><span class="bold"><span class=:big">

with <p> and remove the unused classes. This may considerably reduce the HTML size.

French editors often use such delirious class names as

<p class="texte_courant_avec_indentation">

and this tag is repeated, say, 3,000 times in the text: if you replace it with <p>, you spare 39*3,000=117,000 characters.

[chrisridd]

@Francois_C The zip compression used in epubs is likely to compress all those crazy_long_class_names down anyway, so I doubt you're saving space in the epub. Similarly all those slightly wordy <span class="bold"> ....things - any time you have repeated text that gets compressed really well.

You might save some RAM when the ereader has to open and uncompress the chapter though.

[JSWolf]

Originally Posted by chrisridd

@Francois_C The zip compression used in epubs is likely to compress all those crazy_long_class_names down anyway, so I doubt you're saving space in the epub. Similarly all those slightly wordy <span class="bold"> ....things - any time you have repeated text that gets compressed really well.

You might save some RAM when the ereader has to open and uncompress the chapter though.

You are saving space removing those long class names.

[davidfor]

Originally Posted by JSWolf

You are saving space removing those long class names.

Yes, but as the file is compress, it probably isn't very much. Giving the classes easily understood names helps me a lot more than the small space saving that short names would give.

[DNSB]

Originally Posted by JSWolf

You are saving space removing those long class names.

I just tried an experiment removing my favoured way of managing paragraph styles (as an example, <p class="para"> for default body indented paragraphs) and replacing them with <p>. This did save some space (~ 21Kbytes) in the uncompressed file sizes reported when I opened the epub using 7Zip. OTOH, the size of the compressed epub file changed by a massive 8 bytes. As usual, ASCII text files compress rather well as the attached screen shot shows though the already compressed images are almost incompressible.

Personally, I didn't find the change enough to make changing my default stylesheet a worthwhile project.

The great tragedy of Science — the slaying of a beautiful hypothesis by an ugly fact. — Thomas Henry Huxley

[Divingduck]

Originally Posted by davidfor

Yes, but as the file is compress, it probably isn't very much. Giving the classes easily understood names helps me a lot more than the small space saving that short names would give.

Also true. I think the main issue is as more complex a file is, as more it will tend to be slow. On a reader it is an issue to solve the use of resources anyway. This do not means to use cryptic expressions but to use everything with care and only where it is really necessarily.
There are arguments like on today's reader the issue is not as big as on older readers. True, but that's as well not all the time true too. Have a book with huge files within, complex styles and extensive usage of spans. Then you will find, that a high-end Reader also tend to be slow in navigation within the book. I (sometimes) do not recognize it reading a book page by page but when I navigate within the book it isn't really enjoying me and latest when I'm looking in the coding I see why that happen so often...

[chrisridd]

How complex do you think these files are, @Divingduck? You may be right about them taking more resource to render/navigate, but it would be interesting to try and quantify that.

@DNSB's test showing an 8 byte saving was a good example :-)

I'd imagine more complex pages would require more energy, so you could count the number of page turns per battery charge, but that's such an enormous number already this would be practically difficult.

Could any of the desktop browser performance test suites be used on an ePub?

[JSWolf]

Originally Posted by davidfor

Yes, but as the file is compress, it probably isn't very much. Giving the classes easily understood names helps me a lot more than the small space saving that short names would give.

But it does add to the page number ADE gives you. I like minimal code for more accurate page numbers with ADE.

[DNSB]

Originally Posted by JSWolf

But it does add to the page number ADE gives you. I like minimal code for more accurate page numbers with ADE.

Jon, perhaps you might want to review the Adobe page number synthesis algorithm? Step one is quoted below:

Determine a compressed byte length of each resource which is referenced in the spine, subtracting any known encryption overhead (IV size)

[eschwartz]

The wordiness of nested spans is not an issue so much as the additional effort required to render a more complex DOM.

But I suspect this conversation has outlived its usefulness.
Modify EPUB does not seem likely to include a tool for manipulating default font sizes, that is all that matters for the purpose of this thread -- let's not continue plaguing people with new post notifications for this thread and tricking them into thinking something interesting happened.

[LadyKate]

Not sure if this is the right place but... Was just trying to add a cover to an epub. The current epub has the title page as the first page and I wanted to keep it. I can't seem to find a setting in Modify ePub to "add cover". There is "Insert or replace cover" which replaces the title page "cover" and that's it.

So to sum things up... kinda asking for a new feature of "add cover" whenever you do an update.

[theducks]

Originally Posted by LadyKate

Not sure if this is the right place but... Was just trying to add a cover to an epub. The current epub has the title page as the first page and I wanted to keep it. I can't seem to find a setting in Modify ePub to "add cover". There is "Insert or replace cover" which replaces the title page "cover" and that's it.

So to sum things up... kinda asking for a new feature of "add cover" whenever you do an update.

I do this frequently to have Calibre show the 'Classic" cover (the one that is on my dead tree copy)

You need to 'undo' the current coverpage and IMAGE (symantic) declaration using an editor,
Then Modify or Polish will not stomp on those others , as the are no longer a 'cover'