What plugin(s) would you like to see?

[JSWolf]

I would love a plugin that converts ePub 3 to ePub 2.

[KevinH]

Hi JSWolf,

How would you want it to handle the following:

nav document - keep it or discard it?

html5 specific tags - these don't exist in xhtml1.1 - keep or strip out, or comment out?

epub3 specific attributes such as data-* and epub-type and ...

smil, pls accessibility features - how would you deal with those?

javascripts - how should those be dealt with?

etc.

As you can see it is much easier to go from valid epub2 to epub3 since 3 is generally a superset of 2, but going the opposite way will be quite hard and could easily end up losing lots of pieces and functionality. I am not sure it can be done in any rational way unless the epub3 book used no new features over the epub3 set.

KevinH

[JSWolf]

Originally Posted by KevinH

Hi JSWolf,

How would you want it to handle the following:

nav document - keep it or discard it?

html5 specific tags - these don't exist in xhtml1.1 - keep or strip out, or comment out?

epub3 specific attributes such as data-* and epub-type and ...

smil, pls accessibility features - how would you deal with those?

javascripts - how should those be dealt with?

etc.

As you can see it is much easier to go from valid epub2 to epub3 since 3 is generally a superset of 2, but going the opposite way will be quite hard and could easily end up losing lots of pieces and functionality. I am not sure it can be done in any rational way unless the epub3 book used no new features over the epub3 set.

KevinH

There are a lot of ePub being made by publishers that would work as ePub 2 no problem. These are the ones I want to convert. You dump the NAV, edit the metadata so it's compliant, edit the OPF, remove <section> tags and basically, that's most of the work done. If it is a true ePub 3, then the plugin can say so.

[KevinH]

Hi JSWolf,

This would most likely have to be an input plugin if someone wanted to do it.

- dumping the nav means the user would have to regenerate a new toc.ncx as one might not already exist.

- is it just section tags you want removed? Wouldn't it be better to simply comment them out or make them a div tag with a class name that indicates it was originally a section tag?

- if javascript, smil, pls or any xml islands are present, just import nothing?

- editing the metadata, and the opf is not hard, neither is converting the doctypes

KevinH

[DiapDealer]

Originally Posted by JSWolf

There are a lot of ePub being made by publishers that would work as ePub 2 no problem. These are the ones I want to convert. You dump the NAV, edit the metadata so it's compliant, edit the OPF, remove <section> tags and basically, that's most of the work done. If it is a true ePub 3, then the plugin can say so.

It's a mistake to differentiate between "true" EPUB3s and EPUB3s being sold by publishers today. EPUB3 is EPUB3. A book doesn't HAVE to take advantage of javascript and audio/video/media overlays/etc to be a "true" EPUB3. It just needs to be a valid EPUB3 package. The fact that many of these EPUB3s being sold today could just as easily have been created as EPUB2s is irrelevant.

Writing a plugin that could just "say so" (when encountering something other than one of your "untrue" EPUB3s) would be a feat in and of itself.

Having said that, I'm sure a plugin could be written that could assist with such a conversion, but a one-click output plugin that could handle ALL situations (or gracefully fail in situations when it couldn't) without breaking anything probably isn't in the cards.

In the amount of time it would take someone to supply such a plugin with all the necessary parameters to successfully convert each unique EPUB3 it encountered, the manual changes to the code probably could have been made already.

[JSWolf]

Originally Posted by KevinH

Hi JSWolf,

This would most likely have to be an input plugin if someone wanted to do it.

- dumping the nav means the user would have to regenerate a new toc.ncx as one might not already exist.

- is it just section tags you want removed? Wouldn't it be better to simply comment them out or make them a div tag with a class name that indicates it was originally a section tag?

- if javascript, smil, pls or any xml islands are present, just import nothing?

- editing the metadata, and the opf is not hard, neither is converting the doctypes

KevinH

The toc.ncx does exist as it would not be ePub 2 compatible without. But if the toc.ncx was not to exist, create one based on the nav ToC.

For the javascript, smil, pls, and XML islands, yes, import nothing or a requester to ask to import or import nothing.

Jon

[Doitsu]

IMHO, this is mostly a cosmetic problem for users with slight OCD tendencies, because a properly designed ePub3 book with an .ncx file, can be opened even by the oldest ADE version, because the reading system is supposed to ignore unknown tags.
If a book only has a navigation document all you have to do is generate a TOC with Sigil and export it with the ePub3 output plugin.
If the book didn't have any validation issues other than the issues caused by down-converting it from epub3 to epub2, you'll end up with a valid ePub3 book that can be read with either ePub2 or ePub3 apps.
As for JavaScript, SMIL etc., you can ignore them, because they won't be supported by ePub2 apps anyway.

[EdwardM1966]

Hi,

I like a plugin with which I can change metadata (title, autor) in batch. Like with MP3's in software like MP3 Tag or Tagscanner.

[Doitsu]

Originally Posted by EdwardM1966

Hi,

I like a plugin with which I can change metadata (title, autor) in batch. Like with MP3's in software like MP3 Tag or Tagscanner.

AFAIK, you can already do this in Calibre, which is much better suited for such tasks.

[BetterRed]

Originally Posted by EdwardM1966

Hi,

I like a plugin with which I can change metadata (title, autor) in batch. Like with MP3's in software like MP3 Tag or Tagscanner.

Or maybe this ==>> EPub Metadata Editor

BR

[DiapDealer]

Sigil's probably not ever going to be very "batch" friendly. It's just not geared that way. I'm not saying such a plugin couldn't be written, but that such a plugin wouldn't really benefit from being launched from Sigil in the first place. It would basically need to be a stand-alone application anyway, so why attach it to Sigil at all?

[bookman156]

I'd like a plugin, or something built into Sigil itself, that enabled you to choose whether you wanted to use <em> and <strong> for italic and bold or <i> and <b>. That would probably be best as a Sigil preference I guess.

The ability to add CSS classes easily, as with the Dreamweaver properties panel, would be good too.

It would also be useful to be able to add special characters that aren't currently there to the 'Insert Special Character' menu.

[Doitsu]

Originally Posted by bookman156

I'd like a plugin, or something built into Sigil itself, that enabled you to choose whether you wanted to use <em> and <strong> for italic and bold or <i> and <b>.

If you prefer <em> and <strong>, you could easily add this feature via clips and/or the clip toolbar.

1. Open the clip editor (CTRL+ALT+C)
2. Create two new clips:
a) Clip 1: name: em; text: <em>/1</em>
b) Clip 2: name: strong; text: <strong>/1</strong>

(Both clips need be the first two clips; use the arrow keys to move them to the top if necessary.)

This will allow you to do the following:

a) Highlight text, right-click and select Clips > em/strong.
b) Right-click somewhere in the main toolbar; unhide the Clip Bar, select text and click the em or strong Clip Bar buttons.
c) Select Edit > Preferences > Keyboard Shortcuts. Delete the shortcuts after Italic and Bold (CTRL+I and CTRL+B) and assign them to Clip 1 and Clip 2.

[KevinH]

Those are really not plugin ideas, unless you want a plugin to change *all* occurrences of i and b to em and strong. If so DiapDealer's TagMechanic plugin can handle that easily right now.

As for choosing a tag for a specific piece of text to use or specifying a css class for it, simply use CodeView or Doitsu's clip idea approach. Bookview is really not the place for fine tuning specific tags and css. The current i and b icons when used in BookView actually use internal QWebPage editing commands that are hard coded to use i and b internally as they existed long before em and strong were added to html.

KevinH

[bookman156]

Originally Posted by Doitsu

If you prefer <em> and <strong>, you could easily add this feature via clips and/or the clip toolbar.

Thanks for this. I didn't realise that kind of thing was possible.