Editing metadata - why is this so...? - content.opf

[retace1824]

file - content.opf
Editing the metadata gets this result:

<meta name="calibre:series" content="YOUR SERIES"/>

Press File/Save

changes:

<meta content="YOUR SERIES" name="calibre:series" />

Is it possible that these changes will not happen?

[DiapDealer]

Attribute orders are unimportant. But... I'm fairly certain that Sigil was updated to retain attribute orders some time ago. Are you using an up to date version of Sigil? If not, there's not much that can be done.

[retace1824]

Originally Posted by DiapDealer

Attribute orders are unimportant. But... I'm fairly certain that Sigil was updated to retain attribute orders some time ago. Are you using an up to date version of Sigil? If not, there's not much that can be done.

Sigil 1.9.20.

With this option, the attributes are not shown in the programs.
on devices Iphone and pocketbook.

If you hand-correct on the
<meta name="calibre:series" content="YOUR SERIES"/>
shows.

The question is why: you change one thing, you save it, it changes.
Why?

[DiapDealer]

Originally Posted by retace1824

Sigil 1.9.20.

With this option, the attributes are not shown in the programs.
on devices Iphone and pocketbook.

If you hand-correct on the
<meta name="calibre:series" content="YOUR SERIES"/>
shows.

The question is why: you change one thing, you save it, it changes.
Why?

No. The question is why reading some apps on iPhone and pocketbook are giving relevance to attribute orders when they shouldn't be. It is the programs that are broken, not Sigil.

We will look into whether or not we can preserve that attribute order, but we're not going to put ourselves on the hook for making changes just to fix broken apps that don't follow spec.

[retace1824]

It is the programs that are broken, not Sigil.

maybe the other way around


Looked here
https://idpf.org/epub/20/spec/OPF_2....htm#Section2.3

For example:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlnspf="http://www.idpf.org/2007/opf">
<dc:title>Tale of Two Cities</dc:title>
<dc:creator opf:role="aut">Charles Dickens</dc:creator>
...
<meta name="price" content="USD 19.99" />
</metadata>

version before saving is correct

<meta name="calibre:series" content="YOUR SERIES"/>

Can be made optional, at the user's choice.

[jhowell]

Originally Posted by retace1824

Looked here
https://idpf.org/epub/20/spec/OPF_2....htm#Section2.3

version before saving is correct

That is just an example. That same specification has another example later on where the order of attributes is reversed:

<meta content="org-example-5059463624137734586" name="dtb:uid"/>

[DiapDealer]

maybe the other way around

No. It's not the other way around. The order of attributes is not relevant. Any reading system that relies on the attributes of an opf entry being in a particular order to work properly is broken.

I said we'd look into accommodating these broken programs (if we can do so easily). Don't hurt your chances of this happening by mistakenly defending your position that it's Sigil that's misbehaving here. I can assure you that it's not. Nothing in the spec you quoted supports your position.

[retace1824]

Originally Posted by DiapDealer

I said we'd look into accommodating these broken programs (if we can do so easily). Don't hurt your chances of this happening by mistakenly defending your position that it's Sigil that's misbehaving here. I can assure you that it's not. Nothing in the spec you quoted supports your position.

Thanks

[KevinH]

Sigil changed to maintaining attribute order a while back even though the spec clearly says attribute order is not relevant. This one done to make the Checkpoint diff tool more effective. So I need help to track down which code inside Sigil is involved.

So some questions:

1. Are you hand editing the opf when editing the metadata or are you using the MetaData editor icon/menu?

2. If the opf is open in a tab can you confirm the order is correct before.

3. If an epub3, Before hitting file save can you use the Update Manifest properties (under epub3 tools) then take a look at the metadata order in the OPF tab. If epub2, use Add Sematics to change something in the opf guide, and see if the OPF tab changed.

4. Are you using an external Python with Sigil and if so what version as the Ordered dict in python was not the default in sime early versions and python is used by the metadata editing code?

[DiapDealer]

I can confirm that it happens when editing the opf file manually. I don't even have to do a file/save. Just clicking on a file in the Book Browser makes the opf change from the inserted:

<meta name="calibre:series" content="YOUR SERIES"/>

to

<meta content="YOUR SERIES" name="calibre:series"/>

Inserting the metadata and switching to a different Code View tab and then going back has the same effect.

This being on Windows 10 with Sigil 1.9.20

[DiapDealer]

Clicking on any menu item in Sigil also immediately causes the opf entry to change. With both EPUB3 and EPUB2.

[KevinH]

So something is wrong with the OPF parsing code. It uses TagAtts.h which is definitely ordered. Probably something in inside the BS4 lxml repair parser which is invoked.

I will try to add a bunch of opf debug code to try to see where this is happening. Hopefully not deep inside lxml.

[Doitsu]

IMHO, this is a non-issue.

• That particular metadata entry is only used by Calibre and Calibre-adjacent software.
• The Calibre metadata parser doesn't require any particular attribute order.

Spoiler:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
	<dc:creator opf:file-as="Doe, John">John Doe</dc:creator>
	<dc:language>en</dc:language>
	<dc:title>Nitpicking for dummies</dc:title>
	<meta content="Nitpicking for dummies" name="calibre:title_sort"/>
	<meta content="The art of nitpicking" name="calibre:series"/>
	<meta content="1" name="calibre:series_index"/>
	<dc:date opf:event="modification" xmlns:opf="http://www.idpf.org/2007/opf">2023-01-27</dc:date>
	<dc:identifier id="BookId" opf:scheme="UUID">urn:uuid:d420bc81-9545-4313-b490-8bc75822cda2</dc:identifier>
</metadata>

[DiapDealer]

Originally Posted by Doitsu

IMHO, this is a non-issue.

• That particular metadata entry is only used by Calibre and Calibre-adjacent software.
• The Calibre metadata parser doesn't require any particular attribute order.

Spoiler:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
	<dc:creator opf:file-as="Doe, John">John Doe</dc:creator>
	<dc:language>en</dc:language>
	<dc:title>Nitpicking for dummies</dc:title>
	<meta content="Nitpicking for dummies" name="calibre:title_sort"/>
	<meta content="The art of nitpicking" name="calibre:series"/>
	<meta content="1" name="calibre:series_index"/>
	<dc:date opf:event="modification" xmlns:opf="http://www.idpf.org/2007/opf">2023-01-27</dc:date>
	<dc:identifier id="BookId" opf:scheme="UUID">urn:uuid:d420bc81-9545-4313-b490-8bc75822cda2</dc:identifier>
</metadata>

I'd normally agree. But the reason we changed Sigil to maintain attribute order was so that doing diffs and checkpoints would reveal accurate -- useful -- changes that had been made to an epub.

So we'd probably be looking at this even if it had nothing to do with calibre series metadata. The fact that it affects some broken reading systems is secondary here. Even though metadata order should be irrelevant, we made a decision that Sigil should maintain attribute order as entered. This runs afoul of that.

[KevinH]

Okay, I tracked this down to running the CleanSource::ProcessXML() routine which is done every time the OPF is loaded (and on any other xml files) to make sure they are sane and parseable. A broken OPF is not something anyone wants to happen.

Of course this damn code uses python and lxml deep inside of our bs4 code.

So I will have to see where something misses the change to OrderedDict() which was made in all python code we use.

I am on it.