Metadata link element urls not being updated

[BeckyEbook]

The old version of the file from OP is here. To test it should be enough.

[KevinH]

Yes that did the trick.

I have now committed the changes needed to master to recognize opf metadata links with relative hrefs and to move the target files properly to Misc (to fit the Sigil conventions), and auto update the link href in the opf but keep the file un-manifested.

Because the file is not in the manifest, if you want to edit/change something in the file, you have to use "open with" to edit the linked file as it may be generated with third party software, or be generic xml or json.

I have not played around with or tested deleting the file using the BookBrowser commands yet so there will probably be more to do for that but at least from a point of reading them in and then writing them back out Sigil should now handle that case properly.

KevinH

Originally Posted by BeckyEbook

The old version of the file from OP is here. To test it should be enough.

[thiago.eec]

Originally Posted by KevinH

Yes that did the trick.

I have now committed the changes needed to master to recognize opf metadata links with relative hrefs and to move the target files properly to Misc (to fit the Sigil conventions), and auto update the link href in the opf but keep the file un-manifested.

Because the file is not in the manifest, if you want to edit/change something in the file, you have to use "open with" to edit the linked file as it may be generated with third party software, or be generic xml or json.

I have not played around with or tested deleting the file using the BookBrowser commands yet so there will probably be more to do for that but at least from a point of reading them in and then writing them back out Sigil should now handle that case properly.

KevinH

Thank you for the quick fix, @KevinH . That's great!

[KevinH]

This fix is not a full fix. Although I can use open with to edit the linked metadata file, and based on testing, deleting the file works as well, Sigil has no way of adding an unmanifested file of any sort.

So we either need to create an add "un-manifested" file menu item or alternatively a menu item that can take a file in the manifest and un-manifest so that current ways to add files can still be used.

We should probably think that through? Perhaps a plugin to add linked metadata resources and remove them would be easiest since this feature is not heavily used.

Ideas? Comments?

KevinH

[DiapDealer]

Originally Posted by KevinH

Perhaps a plugin to add linked metadata resources and remove them would be easiest since this feature is not heavily used.

Ideas? Comments?

I've got a plugin that does nothing more than add the iBooks xml file. It could probably be used as a base/template for something like that.

[KevinH]

Originally Posted by DiapDealer

I've got a plugin that does nothing more than add the iBooks xml file. It could probably be used as a base/template for something like that.

Sounds lke a good idea! I think adding menu items to Sigil to deal with un-manifested items would/could cause confusion with novice users especially. Perhaps a plugin is the right way to go here.

[thiago.eec]

Originally Posted by KevinH

Sounds lke a good idea! I think adding menu items to Sigil to deal with un-manifested items would/could cause confusion with novice users especially. Perhaps a plugin is the right way to go here.

I agree. A plugin could be used for handling linked resources (editing, adding, deleting, etc).

Altough, Sigil should be capable of identifing, by itself, the presence of this structure. Otherwise, if a user do not have the plugin installed, then Sigil would delete the file, just like now.

[DiapDealer]

Originally Posted by thiago.eec

Altough, Sigil should be capable of identifing, by itself, the presence of this structure. Otherwise, if a user do not have the plugin installed, then Sigil would delete the file, just like now.

Without the plugin, a user could not create an unmanifested file with Sigil in the first place. So there's nothing to be deleted. A user would need the plugin to create such a file with Sigil.

That's why we're talking about creating the plugin: so that users can create this type of file within Sigil itself.

[thiago.eec]

Originally Posted by DiapDealer

Without the plugin, a user could not create an unmanifested file with Sigil in the first place. So there's nothing to be deleted. A user would need the plugin to create such a file with Sigil.

That's why we're talking about creating the plugin: so that users can create this type of file within Sigil itself.

Maybe I wasn't clear. Image I already have a book with a linked resource. If I don't know about this and open the book on Sigil, do some changes and save, then the file would be deleted.

Sigil should detect the linked resource and let it be, even without the plugin (altough it would be necessary for further actions, such as editing the file).

[DiapDealer]

Originally Posted by thiago.eec

Maybe I wasn't clear. Image I already have a book with a linked resource. If I don't know about this and open the book on Sigil, do some changes and save, then the file would be deleted.

Not any more. That's what Kevin's fix is all about. This single spec compliant, unmanifested file (a properly referenced file in a metadata link element) will not be deleted any more. A plugin will (hopefully) be added so that Sigil users can add this file from within Sigil.

Originally Posted by thiago.eec

Sigil should detect the linked resource and let it be, even without the plugin (altough it would be necessary for further actions, such as editing the file).

It will. In the next release of Sigil. However ...

Sigil is a long way from allowing user-defined archive structures. As such, there are no guarantees that unmanifested files which aren't specifically allowed by the EPUB specs will survive a Sigil save.

This was a one-off fix for your specific issue. Sigil won't delete this spec-compliant, non-manifested file any more (or others if we learn of them). But accommodations aren't going to be made for just any old files that might be included willy-nilly in an EPUB's archive. Sigil currently requires epubs to have a very strict structure. That's not going to change any time soon (even though we all might like it to). That type of functionality is going to require a huge overhaul of Sigil's codebase: something neither of us has the time for right now.

[thiago.eec]

Originally Posted by DiapDealer

This was a one-off fix for your specific issue.

Not really my issue. This is formally on the specs.

Originally Posted by DiapDealer

But accommodations aren't going to be made for just any old files that might be included willy-nilly in an EPUB's archive.

Not any file. It's just about linked resources.



But that's it. I want to say thanks again for the fix, and for the support.
I'll let you guys find the best way to handle this.

[Doitsu]

@thiago.eec Out of curiosity: did you hand-code the Onix file or did you use a custom app? If so which one?

[thiago.eec]

Originally Posted by Doitsu

@thiago.eec Out of curiosity: did you hand-code the Onix file or did you use a custom app? If so which one?

Hi, @Doitsu.

I used the free trial of ONIXEdit (https://onixedit.com/en-us) to produce a template that fits my needs (mostly novels). When I create a new book, I just adapt the template on Notepad ++.

[jcsalomon]

Originally Posted by DiapDealer

Also keep in mind that Sigil's EPUB3 support has not been extended to 3.01 or 3.1 (let alone 3.2). The spec is too volatile to even attempt to keep up.

Following the discussion on the EPUB lists, seems 3.2 is their way of saying, “3.1 was a mistake; nobody uses it, and for good reason; so let’s find a way that complies with standarization rules to roll everything back to 3.01.”

[thiago.eec]

Originally Posted by jcsalomon

Following the discussion on the EPUB lists, seems 3.2 is their way of saying, “3.1 was a mistake; nobody uses it, and for good reason; so let’s find a way that complies with standarization rules to roll everything back to 3.01.”

They say it almost textually on Github:

The next revision of EPUB 3 will be EPUB 3.2, which seeks to update EPUB 3.1 to make a successor that is compatible with EPUB 3.0.1 (i.e., that reverts the package document version number change introduced in 3.1).

Creators of EPUB content are advised not to implement 3.1, but to continue to create content compatible with EPUB 3.0.1 until work on EPUB 3.2 is complete.

And in here, you can see the summary of the situation.