How to Stop Calibre from Automatically Changing OPF metadata

[Sneddles]

I have noticed that Calibre changes the description metadata read from the OPF entry in an epub file. It will convert from plain text to HTML, and even add attributes to existing HTML. It will also replace a </p><p> sequence with <br>.

Is it possible to have Calibre not change the description metadata read from the file?

I have also noticed that, when editing the description, Calibre will automatically add a DIV wrapper around an entry that has multiple <p> entries. Is there a way to stop it doing this?

[theducks]

Originally Posted by Sneddles

I have noticed that Calibre changes the description metadata read from the OPF entry in an epub file. It will convert from plain text to HTML, and even add attributes to existing HTML. It will also replace a </p><p> sequence with <br>.

Is it possible to have Calibre not change the description metadata read from the file?

I have also noticed that, when editing the description, Calibre will automatically add a DIV wrapper around an entry that has multiple <p> entries. Is there a way to stop it doing this?

NO

The Metadata update comes from the Library, if it is the same, you see no change.

I have never seen </p> <p> replaced with a <br />. Your original souce must have some weird error embedded.
I have converted many a book and not seen a <div> used. Again weird SOURCE is the only logical.
Validate your HTML before passing it to Calibre is the only recommendation I can suggest.

[eschwartz]

I have noticed that calibre adds a div around the comments metadata if there is certain types of html in it, which I assume is because of sanitizing. If calibre does it I trust there is a good reason. (@theducks I think this is not a conversion thing, but rather, still metadata update.)

I have never seen the p to br, or any other changes besides the div.

[Sneddles]

Originally Posted by theducks

NO

The Metadata update comes from the Library, if it is the same, you see no change.

I should have made it clear that it happens when importing an epub.

I viewed the original epub content.opf description entry and it was plain text with blank lines between paras. When Calibre imported it the text it was changed to multiple <p class="description"> elements, using the blank lines to delimit the paras, and the <p> elements were wrapped in a <div> element.

I edited the file to remove the <div> elements and re-imported the epub. This time Calibre combined the <p> elements with a <br> element.

I have also seen Calibre wrap multiple<p> elements with a <div> element when editing the description using the metadata editor in Calibre.

Originally Posted by eschwartz

I have noticed that calibre adds a div around the comments metadata if there is certain types of html in it, which I assume is because of sanitizing. If calibre does it I trust there is a good reason.

I can't think of any good reason to wrap using a <div> element.

The OPF spec doesn't state any specific requirements, and there is nothing in the HTML spec that would require it either.

Neither can I think of a good reason to specify a class attribute on the <p> element. The class attribute is useless without an entry in an associated CSS file, and there doesn't seem to be anything in the OPF spec to allow a CSS file to be provided for the .opf file.

[kovidgoyal]

calibre does not change *anything* in any file on import. As for changes to the HTML comments stored in the *calibre* database. They are made for a good reasons, if you want to understand those reasons, read the code.

[eschwartz]

Here is where it is processed: https://github.com/kovidgoyal/calibr...ry/comments.py

@Kovid

I don't see anything there about divs, and my search skills proved woefully inadequate.

Simple curiosity.

EDIT: Thanks, found it!

[kovidgoyal]

That's the sanitization code, you also need to look at the comments_editor.py

[Sneddles]

I had an expectation of how Calibre would work that resulted in me making some assumptions about the behavior I was seeing. For that I apologize.

The behavior I am seeing is that the .azw3 file created from the epub file has the changed description.

I haven't looked at the code for some time, (in my view it doesn't follow Robert Martin's clean code guidelines or the SOLID principles which makes it difficult to read and understand; and I shouldn't need to do so), but I seem to remember that it uses an intermediate form when converting from one format to another.

I never looked at how the metadata is handled, but I am assuming that the data used in the output file is coming from the Calbre database, and not the source file.

So I guess that is how and why the conversion happens.

[kovidgoyal]

Originally Posted by Sneddles

I haven't looked at the code for some time, (in my view it doesn't follow Robert Martin's clean code guidelines or the SOLID principles which makes it difficult to read and understand; and I shouldn't need to do so), but I seem to remember that it uses an intermediate form when converting from one format to another.

If you want to understand something, you need to read the code. No one is going to hold your hand and explain every little detail to you. And if you find the calibre code base hard to follow, you are welcome to ask for pointers as to where to begin. Although, making ill-informed statements about the quality of a codebase you dont understand is not a good way to begin. It says far more about your limitations than those of the code base.

[Sneddles]

Actually it is possible to stop Calibre from making any changes to the metadata in the generated .azw3 file. It doesn't require any changes to Calibre code either.

[Sneddles]

Interesting.

The behaviour of Calibre 1.45 has changed and the description in the .azw3 file is now the same as in the original epub.