[GUI Plugin] Modify ePub

[theducks]

Now I see where you are going

# Save original file when converting/polishing from same format to same format

there is now a tweak now for Polish

[Jade Aislin]

I've just edited some of my custom columns in one library. I wanted to copy the epubs to a different library that may have the epub already, but the metadata I edited reverts back to the original metadata.

I have automerge set to overwrite exsisting duplicate formats.

I tried using this plugin (Modify epub), checking Update metadata. I tried using the Polish feature, checking: update metadata in the book files, update the cover in the book files, add metadata as a 'book jacket' page.

However, when I tried to copy the book to the new library, none of the edited metadata stuck.

Am I missing something? How do I get metadata from custom columns to stick to the book when I copy it to a different library?

[BetterRed]

Originally Posted by Jade Aislin

Am I missing something? How do I get metadata from custom columns to stick to the book when I copy it to a different library?

I dont think you can put custom columns in EPUB metadata - see https://wiki.mobileread.com/wiki/Metadata#ePUB_metadata

I hope I'm wrong because it's something I'd like to able to do too

BR

[JimmXinu]

Originally Posted by Jade Aislin

Am I missing something? How do I get metadata from custom columns to stick to the book when I copy it to a different library?

You might experiment with using 'Save to Disk' in the source library and then adding them to the dest library.

I believe calibre tucks copies of all columns and metadata inside the epub in some non-standard tags.

[theducks]

Originally Posted by Jade Aislin

I've just edited some of my custom columns in one library. I wanted to copy the epubs to a different library that may have the epub already, but the metadata I edited reverts back to the original metadata.

I have automerge set to overwrite exsisting duplicate formats.

I tried using this plugin (Modify epub), checking Update metadata. I tried using the Polish feature, checking: update metadata in the book files, update the cover in the book files, add metadata as a 'book jacket' page.

However, when I tried to copy the book to the new library, none of the edited metadata stuck.

Am I missing something? How do I get metadata from custom columns to stick to the book when I copy it to a different library?

Copy to Library will move/copy all fields that exist in BOTH.
If you have created the destination using with the using Copy Structure from the current (assumes you will use it as the source ), Calibre will do everything.
If you manually created or have modified the other Library: you will need to bring the field structure into synch by hand. NOTE: Custom columns containing 'Fixed values'. The destination needs to include ALL values used in the source table .

[BetterRed]

Originally Posted by JimmXinu

You might experiment with using 'Save to Disk' in the source library and then adding them to the dest library.

I believe calibre tucks copies of all columns and metadata inside the epub in some non-standard tags.

How can one view them - they don't show up the ebook-viewer metadata 'overlay', nor as far as I see in the 'book jacket' (which I don't normally have in my books) and I cant see them in the content.opf file when I open the epub in Tweak nor can I see them Sigil.

They are in the metadata.opf file in the book folder, they're 'tucked away' as entries of the form <meta name="calibre:user_metadata:#columnname"....

I think the content of the embedded metadata is defined by conventions/standards, see Wiki link in my previous post. But maybe there could be something that would allow one to put custom columns into the 'book jacket' - maybe something like Generate Cover.

BR

[BetterRed]

Originally Posted by BetterRed

... maybe there could be something that would allow one to put custom columns into the 'book jacket' - maybe something like Generate Cover.

Well it turns out its already in Calibre, custom columns are easily added to the 'jacket' - see this thread https://www.mobileread.com/forums/sho...d.php?t=148490 starting at post #9

I prefer that the jacket be at the back of the book, so I changed the Add/Replace code to do that.

However, I also prefer to be using factory code, so could an option be added to position the jacket at the back of the book, rather than after the 'titlepage'.

Thanks BR

[Rev. Bob]

Old feature, new user...

Originally Posted by kiwidude

• Remove Adobe resource DRM meta tags - to strip some Adobe cruft of a <meta> tag from the html files.

Any chance you could tweak this feature a little to remove the linefeeds that these (and other deleted meta elements) leave behind?

Also, bug report: the "convert HTML to UTF-8" option produces HTML files without byte order marks. (EDIT: This seems to be an artifact of going through Calibre 0.9.40's repacking routine.)

Another useful feature would be a more general TOC fixer, which could:

• Remove empty class attributes from navPoint elements.
• Correct the playOrder values, if wrong.
• Calculate and fix the dtb:depth value (or set to 1 if the Flatten option is active, of course).
• Ensure that the dtb:uid value matches the OPF file's unique-identifier element's value.
• Specify dtb:totalPageCount and dtb:maxPageNumber as 0, if missing.
• Fill in the docTitle and docAuthor blocks, if missing, with the values from the OPF file.

(Or, if there's another plugin that already handles that...?)

[theducks]

@Rev Bob
Have you tried the 'Edit ToC' PI .
Sometimes, just opening and saving claens things up.

Extra line feeds in the code area is a cosmetic the normal reader does not see.

[Rev. Bob]

Originally Posted by theducks

@Rev Bob
Have you tried the 'Edit ToC' PI .
Sometimes, just opening and saving claens things up.

Except that it also "dirties things up" by adding all the Calibre metadata that I'm not interested in. (I run the Modify ePub plugin at command-line level, specifically to avoid that.) It doesn't seem worth the trade-off...

Originally Posted by theducks

Extra line feeds in the code area is a cosmetic the normal reader does not see.

Normal readers don't see the ADEPT or charset meta tags, either. I figure, if you're gonna remove something, might as well remove it all the way.

[jackie_w]

Originally Posted by Rev. Bob

Except that it also "dirties things up" by adding all the Calibre metadata that I'm not interested in. (I run the Modify ePub plugin at command-line level, specifically to avoid that.) It doesn't seem worth the trade-off...

I wasn't aware that the calibre TOC Editor added any metadata. It's the ncx file being edited, not the opf file, isn't it? Can you give an example of what you mean by "dirtied up"?

[Rev. Bob]

Originally Posted by jackie_w

I wasn't aware that the calibre TOC Editor added any metadata. It's the ncx file being edited, not the opf file, isn't it? Can you give an example of what you mean by "dirtied up"?

Merely importing a book into Calibre adds the metadata. As I understand it, that's a prerequisite to being able to use Calibre's TOC Editor on it...

EDIT: As for an example, I just added an EPUB into my Calibre library, did nothing to it, and used Save to Disk to make a copy. It made the following OPF changes that I consider "dirtying it up":

• Removed the BOM from the file, making it an improper UTF-8 file.
• Moved the title below the author, removing the indentation in the process.
• Modified the date/time.
• Removed the (empty) subject field.
• Inserted Calibre-specific metadata: title_sort, user_categories, and author_link_map (also with botched indentation)
• Inserted a contributor credit for itself.
• Inserted a second, Calibre-specific, identifier field.

You may be fine with those changes. I am not.

[jackie_w]

Originally Posted by Rev. Bob

Merely importing a book into Calibre adds the metadata. As I understand it, that's a prerequisite to being able to use Calibre's TOC Editor on it...

EDIT: As for an example, I just added an EPUB into my Calibre library, did nothing to it, and used Save to Disk to make a copy. It made the following OPF changes that I consider "dirtying it up":

• Removed the BOM from the file, making it an improper UTF-8 file.
• Moved the title below the author, removing the indentation in the process.
• Modified the date/time.
• Removed the (empty) subject field.
• Inserted Calibre-specific metadata: title_sort, user_categories, and author_link_map (also with botched indentation)
• Inserted a contributor credit for itself.
• Inserted a second, Calibre-specific, identifier field.

You may be fine with those changes. I am not.

I believe it's the Save-to-disk which is updating the metadata, not the import or the TOC Edit. I haven't tested this but try Import, then TOC edit then copy (not move, or you'll mess up the library) from calibre library directory to whereever using the Op Sys. I realise this is not 'recommended practice' but if you're careful it may give you what you want.

[Rev. Bob]

Originally Posted by jackie_w

I believe it's the Save-to-disk which is updating the metadata, not the import or the TOC Edit. I haven't tested this but try Import, then TOC edit then copy (not move, or you'll mess up the library) from calibre library directory to whereever using the Op Sys. I realise this is not 'recommended practice' but if you're careful it may give you what you want.

That's a whole lot more effort than I'd like to have to put into the process. By comparison, I can currently right-click on an EPUB in Windows Explorer and select an option from its context menu to execute the "Modify ePub" script with my chosen options. I get a modified copy of the EPUB in the original directory within seconds.

Yes, granted, setting up the context menu option was a bit of a hassle, but once that was done...

EDIT: Inspecting the Calibre version of the above example in place, I do find that the OPF is intact there; it's even still a true UTF-8 file. However, the "open and save the TOC in Calibre's editor" recommendation resulted in a broken TOC, in that the dtb:depth had been improperly changed from 2 to 3. In addition, the !DOCTYPE had been removed, Calibre had added itself in as a new dtb:generator element, and (oddly) the content and name attributes of the meta elements had switched places, which serves no purpose beyond making the data hard to decipher. The only reason I can imagine why that should happen is that the parser is mindlessly alphabetizing attributes, which is a bad idea in this context.

Further, looking at the actual navPoint elements, all of the perfectly good, logical ID values (like "copy" for the copyright page, "intro" for the introduction, "pt03" for Part 3, "ch05" for Chapter 5, et al.) had been replaced with mile-long UUID values. That is in no way the "minimal change" level that I'm after; I want a process that does exactly what it's told - no more, and no less.

[Man Eating Duck]

Originally Posted by Rev. Bob

Also, bug report: the "convert HTML to UTF-8" option produces HTML files without byte order marks. (EDIT: This seems to be an artifact of going through Calibre 0.9.40's repacking routine.)

This might be a nitpick, but this is probably not a bug, as a BOM is apt to create more problems than it solves in my experience. The Unicode standard does not recommend that one is used, as is also mentioned in the linked Wiki section. Do you have a specific use case where it is needed?