[GUI Plugin] Modify ePub

[foosion]

Originally Posted by theducks

It is a Calibre Tweak
ID: save_original_format

When calibre does a conversion from the same format to the same format, for example, from EPUB to EPUB, the original file is saved, so that in case the conversion is poor, you can tweak the settings and run it again. By setting this to False you can prevent calibre from saving the original file. Similarly, by setting save_original_format_when_polishing to False you can prevent calibre from saving the original file when polishing.

Setting both to False worked.

[DNSB]

I think I've complained about the before but when Remove non-DC metadata elements is checked, the DC Modified item is removed. It is the only mandatory for ePub3 property that does not start with <dc: but it's an annoyance having to restore it.

<meta property="dcterms:modified">2025-03-23T18:40:12Z</meta>

[kiwidude]

Originally Posted by DNSB

I think I've complained about the before but when Remove non-DC metadata elements is checked, the DC Modified item is removed. It is the only mandatory for ePub3 property that does not start with <dc: but it's an annoyance having to restore it.

<meta property="dcterms:modified">2025-03-23T18:40:12Z</meta>

This isn't a plugin I use personally beyond a couple of most basic features once in a blue moon, and certainly not a niche feature intended for book publishers like this one.

Obviously ePub3 didn't exist back in 2011 when this plugin feature was written. To change this will require not just a change in this plugin, but also a change to the Quality Check plugin to make it skip this attribute.

It shouldn't be a majorly difficult change (I hope), will put it on the list.

[kiwidude]

Release Notes
https://github.com/kiwidude68/calibr...fy_epub-v1.8.6

I still need to make the matching change to Quality Check later...

[DNSB]

Originally Posted by kiwidude

This isn't a plugin I use personally beyond a couple of most basic features once in a blue moon, and certainly not a niche feature intended for book publishers like this one.

Obviously ePub3 didn't exist back in 2011 when this plugin feature was written. To change this will require not just a change in this plugin, but also a change to the Quality Check plugin to make it skip this attribute.

It shouldn't be a majorly difficult change (I hope), will put it on the list.

I've been using that feature to remove the mass of useless information that some self-published epubs seem to have—an .opf file that runs over 3000 lines is ridiculous. Sigil and calibre's ebook-editor will fix that issue automatically by inserting a line with the current modified date but I would prefer to maintain the original modified date.

Thanks for the change!

[DNSB]

Got around to doing more testing with the updated plugin and it spits out an error message when I attempt to modify more that one file at a time. My test was with 3 files and got the error message after clicking Yes to replace the versions in the library (the log file prior to clicking yes did not show any errors). Doing those 3 files one at a time did not generate the error message.

calibre, version 8.0.1
ERROR: Unhandled exception: <b>AttributeError</b>:'NoneType' object has no attribute 'update_last_modified'
...
Traceback (most recent call last):
  File "calibre_plugins.modify_epub.dialogs", line 291, in do_book_check
  File "calibre_plugins.modify_epub.dialogs", line 310, in do_close
AttributeError: 'NoneType' object has no attribute 'update_last_modified'

[kiwidude]

@DNSB - that isn't something I have been able to replicate, nor does it look in any way related to the change I made. That error message looks like somehow the plugin dialog has been unable to find the current database object. TBH I haven't even seen the prompt for so long (I have it turned off in configuration options for that plugin), but I selected 3 books, did an add/replace cover, and it all worked fine.

Is it only on specific Modify ePub options being ticked? In which case there must be more error messages or log somewhere, PM me the full log.

[DNSB]

Getting rather weird. It only happened on my Intake library. So I created a new library copying the structure of the Intake library and copied the contents of my Intake library there. After the copy, I could happily Modify ePub the contents of Intake2 without getting the error message after clicking on yes. I then deleted the original Intake library, created a new one after deleting the contents of the Intake directory, copied everything back from the Intake2 library and no issues running Modify ePub.

When I was playing with my original Intake library after moving the contents to Intake2, I copied 5 files from my Main library and they came up with the same error message. So something in the library or it's structure caused the issue but, as the old sign I had above my desk at work said, We don't believe in miracles, we just depend on them.

I've attached my Modify ePub configuratin screen and the calibre debug error logs. Once again, thanks for your help and feedback.

[VapidRapidReader]

I had this error since upgrading to Calibre 8.12:

Failed to modify ePubs: Failed: Modify ePubs version (1, 8, 6)

The error seems to come from:

ImportError: cannot import name 'RECOVER_PARSER' from 'calibre.ebooks.oeb.parse_utils' (C:\Program Files\Calibre2\app\bin\python-lib.bypy.frozen\calibre\ebooks\oeb\parse_utils.pyc )

I tried both jointly and separately to replace a cover and update metadata. This occurs if I try a single book or a group.

[VapidRapidReader]

From another thread:

Originally Posted by kovidgoyal

RECOVER_PARSER is gone because of bugs in lxml in windows, https://bugs.launchpad.net/lxml/+bug/2125756. I dont know why any plugins would have been using it, the correct way to parse html is to use the parse_html function from calibre.oeb.parse_utils. But if plugins want to parse html or xml using lxml directly, the relevant functions are safe_xml_fromstring and safe_html_fromstring from the calibre.utils.xml_parse module. And if they really, really want to use RECOVER_PARSER then can simply define it themselves as

from lxml import etree
RECOVER_PARSER = etree.XMLParser(recover=True, no_network=True, resolve_entities=False)

Note that I strongly recommend against using RECOVER_PARSER as it is fundamentally broken thanks to the bug in lxml linked to above.

[Capricorn]

Yes, on upgrading to 8.12 from 8.11.1, I now get the same error.

[JSWolf]

I've modified Modify ePub to work with calibre 8.12. I've upped the version to 1.8.7. This is a beta version. Please report any errors.

[DNSB]

Please note the @JSWolf's modification to Modify Epub and Quality Check are iffy since they continue the use of lxml. A proper rewrite to use parse_html function is quite a bit more work.

[JSWolf]

Originally Posted by DNSB

Please note the @JSWolf's modification to Modify Epub and Quality Check are iffy since they continue the use of lxml. A proper rewrite to use parse_html function is quite a bit more work.

My fixes are using the code that Kovid pasted. It gets the plugins working under 8.12. I have no idea if it's the best way to do it. At least they can be posted as working and then fixed the better way.

[DNSB]

Originally Posted by JSWolf

My fixes are using the code that Kovid pasted. It gets the plugins working under 8.12. I have no idea if it's the best way to do it. At least they can be posted as working and then fixed the better way.

The problem is that the same issues with lxml as mentioned in Kovid's bug report are still present in your modification that simply adds the direct RECOVER_PARSER definition (and adds a second instance of the "from lxml import etree" line. I looked at the parse_html documentation and examples and it's a lot more work than I am able or willing to do. Not to mention the need to test those changes.