[GUI Plugin] Modify ePub

[jackie_w]

But, which epub devices would you be targetting? Sony PRS505 through to PRS650 family already have this feature in the PRSPlus custom software. PRST1 has it in Morkl's custom EbookReader app. All Kobos allow customised on-device font as a standard feature for main book text plus there's an option in the standard calibre Kobo driver which can be used to fine-tune 'special' fonts (e.g. smallcaps, dropcaps, monospace etc). Although I have to confess I'm not sure what Nooks can do with custom on-device fonts.

Modify Epub already has an option to Append extra CSS.

[theducks]

Originally Posted by Perkin

I have an idea for an added extra feature...

Seeing as quite a few e-readers now allow a user to load their own fonts onto a device, would it be possible to have an added css feature, when stripping embedded fonts to allow instead of stripping the references to those fonts have the src point to a device resource font instead.
- could possibly have a list of fonts which would be redirected
- would have to probably have a text box with a 'device font path', which would be up to user to make sure that it is correct.

The main reason I ask, is that I have a lot of epubs with several common fonts (Charis being main one) and would like to reduce the size footprint of the epubs, but not have to miss the correct fonts being used.

What do you think?

I kind of like this idea, but isn't it device dependent?
I believe my device uses something like

src: url("res:///fonts/TestFonts.ttf")

This would make it a Per Device (driver level?) setting, with a prior-to-send scan for device available fonts: 0)Leave book as is.
1)Modify to use any Device fonts, removing those embedded fonts from the book. 2)Remove all Embedded fonts but use any device resident font, (assumes CSS has a fallback coded). 3)Removal all @fonts and embedded fonts

[Perkin]

Originally Posted by theducks

I kind of like this idea, but isn't it device dependent?
I believe my device uses something like

src: url("res:///fonts/TestFonts.ttf")

That's why I thought...

- would have to probably have a text box with a 'device font path', which would be up to user to make sure that it is correct.

Which *you* would enter

res:///fonts/

I was only thinking single user/device(manufacturer?) usage though.
As has been pointed out for more wider usage would have to be in output/driver PI.

[Rev. Bob]

Here's a feature I'd like: a Kobo-DRM equivalent to the "remove ADEPT tags" feature.

The liberated Kobo books have a JavaScript file that gets included in the pages, a couple of lines of CSS that are likewise pasted in, and a ton of SPAN tags that no longer serve any purpose besides cluttering up the code. Like the ADEPT case, the DRM's already been removed; this is simply about cleaning up the mess it left behind.

Similarly, an option to remove SPAN tags with no attributes, and to merge adjacent SPAN tags with the same attributes, would also be nifty. Phoenix Pick is horrible about that last one. Merging adjacent or empty bold/italic tags would also be useful; cases like </i><i>, <i/>, and <b></b> should always be removed.

[PeterT]

Um... The spans and java script are an integral part off the bookmark support in the kepub reading engine

[Rev. Bob]

Originally Posted by PeterT

Um... The spans and java script are an integral part off the bookmark support in the kepub reading engine

And some of us would rather have standard, clutter-free, non-kepub EPUB books.

[PeterT]

So why not ask for a plugin to convert from kepub to epub as that IS what you want.

[Rev. Bob]

Originally Posted by PeterT

So why not ask for a plugin to convert from kepub to epub as that IS what you want.

Because, so far as I can tell, what I specified are the only differences? Hardly seems like enough to justify a full plugin.

[davidfor]

I can see stripping the javascript and CSS as part of Modify ePub. Removing the spans should be done as an input plugin for the conversion. Then it is used during a conversion from kepub to any other format.

[PeterT]

Originally Posted by Rev. Bob

Because, so far as I can tell, what I specified are the only differences? Hardly seems like enough to justify a full plugin.

I've spent some time this week looking at things, and unfortunately, removing the span's can not be done in the same manner as the other cleanups are done by this plugin. Many of the cleanups are done by using regular expressions against the raw (x)html files that make up the book. Unfortunately, spans CAN be nested (and in fact, were in some of the kEpubs from Kobo that I was playing with.

The challenge is that while it is trivial to handle a non nested span (something along the lines of

<span.+?id="kobo[\d.]+.*?>(.*?)<\/span>

it breaks down dramatically when there is an internal span.

The testing book with nested span's I was using contained the following markup

<p class="indent">
<span id="kobo.114.1">I don’t go in for ‘lawn maintenance’, though — all that weeding and feeding.</span>
<span id="kobo.114.2"> I prefer my ‘weeds’: the clover, which keeps the grass naturally green with its nitrogen-fixing nodules; the daisy, opening and closing each day (its name comes from the Old English <em>daeges <span class="ent1">ē</span>age</em>, meaning ‘the day’s eye’); the little blue-purple <em>Prunella</em>, known as ‘self-heal’, used to treat sore throats, mouth <a id="page_184"></a>ulcers and open wounds — and still used in modern herbal medicine as an astringent for external or internal wounds.</span>
<span id="kobo.114.3"> As Vita Sackville-West said, ‘A weed is only a plant in the wrong place.’ To which we should add: ‘or one for which we haven’t yet discovered the use’.</span>
</p>

Note the nested span in the kobo.114.2 span.

[Rev. Bob]

Originally Posted by PeterT

I've spent some time this week looking at things, and unfortunately, removing the span's can not be done in the same manner as the other cleanups are done by this plugin. Many of the cleanups are done by using regular expressions against the raw (x)html files that make up the book.

Well, drat. I was hoping it was something more like an XSLT transformation, node-aware. It'd be a lot easier in that context...

[davidfor]

Originally Posted by Rev. Bob

Well, drat. I was hoping it was something more like an XSLT transformation, node-aware. It'd be a lot easier in that context...

Part of the problem is that Modify ePub doesn't really change the html code. Most of the changes are to the rest of the epub. It is only the "HTML & Styles" options that do and most of them are changing things in the header of the HTML files or elsewhere. In fact, I think "Smarten punctuation" is the only option that changes anything inside the body tags. And I'm pretty sure it calls a calibre function.

And yes, using an XSLT transformation would probably make this easy. It could probably be done with BeautifulSoup without to much problems. But, again, I think this belongs as a calibre conversion plugin and it would need to look at what it uses for this.

[eschwartz]

Originally Posted by PeterT

I've spent some time this week looking at things, and unfortunately, removing the span's can not be done in the same manner as the other cleanups are done by this plugin. Many of the cleanups are done by using regular expressions against the raw (x)html files that make up the book. Unfortunately, spans CAN be nested (and in fact, were in some of the kEpubs from Kobo that I was playing with.

The challenge is that while it is trivial to handle a non nested span (something along the lines of

<span.+?id="kobo[\d.]+.*?>(.*?)<\/span>

it breaks down dramatically when there is an internal span.

The testing book with nested span's I was using contained the following markup

<p class="indent">
<span id="kobo.114.1">I don’t go in for ‘lawn maintenance’, though — all that weeding and feeding.</span>
<span id="kobo.114.2"> I prefer my ‘weeds’: the clover, which keeps the grass naturally green with its nitrogen-fixing nodules; the daisy, opening and closing each day (its name comes from the Old English <em>daeges <span class="ent1">ē</span>age</em>, meaning ‘the day’s eye’); the little blue-purple <em>Prunella</em>, known as ‘self-heal’, used to treat sore throats, mouth <a id="page_184"></a>ulcers and open wounds — and still used in modern herbal medicine as an astringent for external or internal wounds.</span>
<span id="kobo.114.3"> As Vita Sackville-West said, ‘A weed is only a plant in the wrong place.’ To which we should add: ‘or one for which we haven’t yet discovered the use’.</span>
</p>

Note the nested span in the kobo.114.2 span.

Multiple passes?

[PeterT]

Originally Posted by eschwartz

Multiple passes?

Why don't you give it a try? The challenge is how to match-up the correct <span> </span> pairs....

[eschwartz]

Originally Posted by PeterT

Why don't you give it a try? The challenge is how to match-up the correct <span> </span> pairs....

I'd usually search for

<span[^<>]*>([^<>]*)</span>

to get the innermost one. Once that is gone, a second pass should get rid of the outer one, shouldn't it? Unless there are other tags involved, in which case it only works some of the time.

So we'd have to use negative lookahead, as such:

(?:(?!<(?:span|/span)>).)*

to match the content inside span tags, without matching span inside span.

Final regex:

<span[^<>]*>((?:(?!<(?:span|/span)>).)*)</span>

EDIT: closing the span tag in the negative lookahead means we need to account for classes, so we will just look for and reject

<(span|/span)

which works as well, I think.

Final regex:

<span[^<>]*>((?:(?!<(?:span|/span)).)*)</span>