[GUI Plugin] Modify ePub

[Cdesja5]

Originally Posted by kiwidude

@Cdesja5 - it doesn't sound like something appropriate for this plugin and it isn't clear what "date" you are talking about. Do you mean book metadata (like published date), or do you mean the metadata jacket html page that you can optionally insert? If you mean the former, IIRC calibre writes in UTC format which is universally handled and I doubt Kovid would want to offer a change, it should be whatever reading device you have that handles that.

If you mean the latter (a jacket page) then again it isn't the responsibility of this plugin. You might be able to customise the date format by customising the jacket template file, which there are instructions for on the forum if you do a search. Either way it isn't something that belongs in this plugin - the plugin calls calibre code to apply metadata/insert jackets, so if you want that data different it is calibre code that needs to be changed.

Thanks for the suggestion, I'll try it out...

[JSWolf]

I've found a problem with the Remove broken TOC entries in NCX file.

First thing, it doesn't fix the playOrder and leave things out of order. Second, FlightCrew is not liking things like </content>

Incorrect according to FC

<content src="OEBPS/Gaba_9780440335153_epub_qts_r1.htm">
</content>

Correct according to FC

<content src="OEBPS/Gaba_9780440335153_epub_qts_r1.htm"/>

The error FC is spitting out is no character data is allowed by content model.

Once all these are fixed, I'd expect FC to complain about the playOrder not being in sequential order due to the removal of any unused entries.

[JSWolf]

Any word on if Remove broken TOC entries in NCX file is going to be fixed?

[kiwidude]

As I mentioned in another thread, anything that FlightCrew or ePubFix reports has about a 0.1 priority in my opinion. If people report that the book doesn't actually work on their specific reader then fair enough, but FC spits out so much nonsense I ignore it. Likewise with play order. The latter I am more likely to fix sometime, but neither appear to be a priority in comparison to other things I am working on.

[JSWolf]

Originally Posted by kiwidude

As I mentioned in another thread, anything that FlightCrew or ePubFix reports has about a 0.1 priority in my opinion. If people report that the book doesn't actually work on their specific reader then fair enough, but FC spits out so much nonsense I ignore it. Likewise with play order. The latter I am more likely to fix sometime, but neither appear to be a priority in comparison to other things I am working on.

I ran the ePub through ePubCheck and the only thing it complained about was the playorder being out of sequence. Can this please be fixed?

The other errors are probably due to a bug in FlightCrew. I'll report it over in the Sigil forum.

[kiwidude]

Changes in this release:

• Rewrite the playOrder to make sure it is an incremental sequence after actions that delete from the TOC.
• Change indenting xml from mucking up self-closing tags in NCX.

[JSWolf]

Originally Posted by kiwidude

Changes in this release:

• Rewrite the playOrder to make sure it is an incremental sequence after actions that delete from the TOC.
• Change indenting xml from mucking up self-closing tags in NCX.

Thanks for the fixes. I'll test them sometime this weekend.

[Perkin]

I have to admit, I haven't read through all the posts to see if this has been requested, as I think it's fairly unique.

Can there be an option to alter the 100% height in the titlepage.xhtml to 99%.

In a couple of s/w readers a scrollbar appears, and you need to page twice to go to next page, rather than the proper once.

I know it's just a personal niggle and isn't high priority. Would be nice though .

[JSWolf]

Originally Posted by Perkin

I have to admit, I haven't read through all the posts to see if this has been requested, as I think it's fairly unique.

Can there be an option to alter the 100% height in the titlepage.xhtml to 99%.

In a couple of s/w readers a scrollbar appears, and you need to page twice to go to next page, rather than the proper once.

I know it's just a personal niggle and isn't high priority. Would be nice though .

Which S/W readers exhibit this behavior?

[Perkin]

Well bu**er me, I just went through several of the previous reading software that I'd had installed (on my tablet) and none of them do it any longer.

I didn't mess with settings too much, which I did originally to get my preferred style (pretty vanilla, as epub should be displayed - no backgrounds or fancy fonts as defaults, just plain black text on white background and fonts/margins/lineheights as defined in epub.) etc.

I do know Calibre' viewer *used* to do it, but hasn't for several weeks (I think since the paged mode was introduced) or maybe earlier.

[Man Eating Duck]

Hi! This is a very useful plugin, which is par for the course for kiwidude, thanks again for your valuable plugins

I see an issue which causes Sigil validation (and epubcheck) to fail. I'm not sure if it's a bug or a validation issue? Sigil says:

The "role" attribute is not an allowed attribute of the <creator> element.

The offending line is

    <dc:creator xmlns:ns1="http://www.idpf.org/2007/opf" ns1:file-as="Author, The" role="aut">Author, The</dc:creator>

(name changed to protect the innocent)

The workaround is trivial, as changing it to ns1:role="aut" fixes it. Is this a bug or am I doing something strange?

On a side note I'll chime in about the remove non dc:metadata option: while it's little hassle to run it twice, it's fairly counter-intuitive that it *doesn't* remove non dc:metadata if you also update metadata. I just do it in two passes, so it's no big issue at all, but I'd prefer the non dc removal to be run last

[kiwidude]

@Man Eating Duck - IIRC there is no code in this plugin that manipulates the creator. It calls stock calibre code for updating the metadata like that. So I believe you will need to point that one towards Kovid if he doesn't spot it - it only happens when you tick the "Update metadata" box right?

Re the remove non dc:metadata option. Yeah I agree it isn't ideal how it works currently, but it isn't trivial to change which is why it was on the bottom of the priority list. This plugin basically does the following:
- unzips the epub
- applies all modifications except update metadata
- rezips the epub
- calls calibre code to update metadata that requires a zip

So in order to move the non dc check, the epub has to be unzipped and rezipped a second time, which isn't "ideal". But if it is the only way to make the function useful then so be it, will take a look sometime since other features/functions of this plugin seem to have stabilised.

[Man Eating Duck]

Originally Posted by kiwidude

@Man Eating Duck - IIRC there is no code in this plugin that manipulates the creator. It calls stock calibre code for updating the metadata like that. So I believe you will need to point that one towards Kovid if he doesn't spot it - it only happens when you tick the "Update metadata" box right?

Yes, only when I use the "Update metadata" feature. I'll do some more testing, and I'll notify Kovid if there is an issue with other books as well.

Originally Posted by kiwidude

So in order to move the non dc check, the epub has to be unzipped and rezipped a second time, which isn't "ideal". But if it is the only way to make the function useful then so be it, will take a look sometime since other features/functions of this plugin seem to have stabilised.

Don't bother, it takes only a few seconds extra when you're aware of it. Maybe you could mention it in the tooltip, but for me it's not an issue at all.

Thanks again, you seem to have an uncanny ability to predict my needs with your plugins

[Man Eating Duck]

Originally Posted by kiwidude

So in order to move the non dc check, the epub has to be unzipped and rezipped a second time, which isn't "ideal". But if it is the only way to make the function useful then so be it, will take a look sometime since other features/functions of this plugin seem to have stabilised.

Sorry to bother you with this again, the answer is probably obvious, but: I had a look at the source, and wonder why you can't update metadata right before unzipping/rezipping instead of afterwards? This allows the non-dc code to do its thing in peace. I tried it, and it does seem to work. There's probably a reason why it breaks something, I just can't spot it

[kiwidude]

@Man Eating Duck - off the top of my head I'm not sure if there are any other combinations of options that might conflict with doing that. For instance doing cover updates or something. Or maybe I was protecting myself against some future option which hasn't eventuated.

If we can't think of a flaw then I will make the same change. In which case I would move that "Remove non dc: metadata" option into the last group just below Update Metadata too I think.