[Plugin] ePub3-itizer - epub3 output plugin for Sigil

[BeckyEbook]

@KevinH: I can confirm that ePub3-itizer never remembered the target folder and I mention that it irritates me too The default target folder is not the happiest choice for Windows users.

It can be solved:
1) add a configuration for the plugin where the target path for epub3 files would be saved
2) without configuration: it is enough for the plugin to read the "[mainwindow]" section from the sigil.ini file and take the path to the first element from the "recentfiles" entry.[*]
[*] It is possible to read the path to the currently opened file (as long as user does not open multiple instances of Sigil and edit many files at the same time).

@AlanHK: Your suggestion to add to OPF file

<meta property="ibooks:specified-fonts">true</meta>

probably fits better with the AddiBooksXML plugin by @DiapDealer, which can be extended with this option.

[KevinH]

Actually, if you load an epub via an input plugin, there is no file path (the epub only exists internally to save-as is done, so we won't be adding any new settings to pass to plugins. I will simply store the last folder used in the plugin's own prefs and go from there.

[KevinH]

But ibooks stuff is not something for ePub3itizer. I will look into why the last folder used is not being set and used.

Originally Posted by AlanHK

Not for me, have to start over in "Documents and settings" every time.


I don't just send the file out without checking it, and I do epubcheck compulsively.
But fixing the same setting every time I do a conversion is something that programs do more reliably, and faster, than people.

I literally only found out today what the "linear" property does, after editing and distributing epubs for about 10 years, and just shrugging off the ugly extra TOC at the back as something I had to put up with. It's not a well known feature.
There are a couple of other options that would be useful: e.g. to optionally add
<meta property="ibooks:specified-fonts">true</meta> to the OPF so embedded fnts will work in i-devices.

Also easily done manually, if you know you need to do it and know the syntax.

[BeckyEbook]

Of course I understand that.
And can't we use get_epub_filepath in other situations?

[DiapDealer]

Originally Posted by BeckyEbook

@AlanHK: Your suggestion to add to OPF file

<meta property="ibooks:specified-fonts">true</meta>

probably fits better with the AddiBooksXML plugin by @DiapDealer, which can be extended with this option.

I'm no longer maintaining that plugin. From what I understand, the xml file is no longer strictly necessary (which is all that plugin was ever intended to quickly inject). It's not equipped to manipulate the opf file, nor I'm I inclined to modify it to do so. Someone else is free to take up the mantle, though.

[BeckyEbook]

XML file is for EPUB2 (your plugin is OK), metadata for EPUB3:
https://help.apple.com/itc/booksasse...l#itc2cf4d26eb

I was thinking of a plugin version that would both add the XML file OR metadata depending on the EPUB version.
I don't like auto-editing an OPF file – maybe I don't know a good way. But I do it anyway

[KevinH]

Just use a good xml parser and all should work easily. Internally we use sigil_bs4 with the lxml parser set forxml. It works just fine.

[AlanHK]

Originally Posted by BeckyEbook

@AlanHK: Your suggestion to add to OPF file

<meta property="ibooks:specified-fonts">true</meta>

probably fits better with the AddiBooksXML plugin by @DiapDealer, which can be extended with this option.

If you've already embedded fonts in the epub2, why would you think you needed to run that again? (If you did, it will add a duplicate of the font definitions each time.) And if you knew this line was necessary, you can just paste it in yourself. It's another thing that is simple to do but took me years to discover. I gave epubs to people to read on iPhones ands iPads, unaware that they were not seeing the fonts I had embedded till they sent me a screenshot to explain another issue.

Anyway, why not just add
<meta property="ibooks:specified-fonts">true</meta> to every epub3 created? I can't think of a reason not to do that. If you have embedded fonts, you want them to work everywhere, obviously. Otherwise, it does nothing.

And on the "linear" tag:
currently the plugin creates the nav file and puts this in the OPF:
<itemref idref="navid"/>

if you don't want to complicate the plugin with options, make that
<itemref idref="navid" linear="yes"/>

which has the same effect, as it's the default, but makes it a bit more obvious what to change if you want to hide the nav page.

[DiapDealer]

Originally Posted by AlanHK

Anyway, why not just add
<meta property="ibooks:specified-fonts">true</meta> to every epub3 created? I can't think of a reason not to do that. If you have embedded fonts, you want them to work everywhere, obviously. Otherwise, it does nothing.

Because it's proprietary nonsense that people who have no intention of embedding fonts (let alone selling it on the iBooks platform) should have to have foisted upon their epubs just because they converted them to epub3?

[KevinH]

Again, I have no plans to add ibooks specific crud.

And linear="yes" makes no sense! Not using a linear attribute at all defaults to linear being "yes". So there is never a need to use "linear="yes". That is the spec.

I personnaly would prefer nav be set to linear="no" which would force the machine readable nav to not be shown as the Reader itself normally has a TOC function that displays the nav or ncx if I was going to add anything at all.

[KevinH]

What I could do is check the epub2 guide for a toc entry (meaning an html toc exists) and if so set the nav to linear="no" so two tocs do not show up in the reading order.

Would that help?

[AlanHK]

Originally Posted by KevinH

And linear="yes" makes no sense! Not using a linear attribute at all defaults to linear being "yes".

You know that. How many people using the plugin do? Or even know what "linear" means here?
I did not until yesterday after I spent hours looking around not knowing what I was looking for. Having the default actually written down would have given me a clue.

Originally Posted by KevinH

So there is never a need to use "linear="yes". That is the spec.

The point is, you (or actually, people who aren't so familiar with the spec, like me) can see where to put "no".

I suggested "yes" as it would not change the current result. Making it "no" would be what I would want 99% of the time. So I would be happy with that.

Originally Posted by DiapDealer

Because it's proprietary nonsense that people who have no intention of embedding fonts (let alone selling it on the iBooks platform) should have to have foisted upon their epubs just because they converted them to epub3?

Yes, it's proprietary nonsense. So is a lot of Amazon's stuff that we have to put up with if we use Kindle. And we have to accommodate Apple's nonsense if we use their hardware. If I want it to work on my iPad or my daughter's iPhone, I need to foist it into the OPF. We live in a proprietary world.
Having that line improves the formatting on a very popular platform, and has no effect otherwise, so again, aside from bloating the file by 52 bytes, what harm is done?

I brought these up because they are tweaks that I have to do every time I do an epub3 conversion. Ideally, they could be options in the plugin, either gui or some kind of ini file.

If no options are allowed, the above were suggested defaults that I think many users might find helpful.

Failing that, could be documented in a readme; there is none with the plugin now.

So, won't bug you about this any more.

[DNSB]

Originally Posted by AlanHK

You know that. How many people using the plugin do? Or evcen know what "linear" means here?
I did not until yesterday after I spent hours looking around not knowing what I was looking for. Having the default actually written down would have given me a clue.

Moi? You don't read standards documents? If nothing else, some of them should come with a warning about not operating heavy machinery within 24 hours of reading more than 1 paragraph.

[KevinH]

All the docs are in the first post here. There is no readme as there is no configuration needed for the plugin.

Nothing ibooks related will be added as not everyone uses ibooks. I read exclusively on my ipad and my iphone and there are many good epub apps that do not require ibooks non-standard crud to work properly. I used them.

I will check if a toc exists in the epub2 guide and if so add linear="no" to the nav entry in the spine. I will add a last stored folder location and code to use the same folder as the epub2 (if it is provided).

If you want something else then ask for help on python from someone else and tweak the plugin to do exactly what you want. It has a GPL license. Make your own version and use it locally.

[KevinH]

See the first post in this thread for the download zip.

New features:

1) much smarter choice for output folder using both last directory
and current epub2 file path and name

2) if an HTML "toc" entry exists in the guide, add linear="no" to nav spine entry to prevent duplicate tocs appearing in the reading order.

Hope this helps,

KevinH