Cover isn't necessarily specificed in metadata about epub-rs

[danigm]

Would you accept a PR exploring that direction?

Yes, sure. Any improvement is welcome. If the API doesn't change and we just add new methods it's better, but don't hesitate to rework some of the public functions if it's needed, we can do a mayor release.

[danigm]

A naive solution I can think of would be to try to retrieve the cover metadata, and if it fails to look up in the manifest for the item containing the cover-image property, and return its id.

Yes, that could improve the behavior, add some kind of fallback to try to find the cover could be a good idea.

[thibaultamartin]

A deeper issue seems to be that some information in the metadata and manifest is lost when the fill_document function is called.

I was thinking about creating the following struct:

struct Node {
    id: Option<String>,
    href: Option<String>
    refines: Option<String>,
    property: Option<String>,
    content: Option<String>,
}

And then adding two Vec<Node> in EpubDoc: one to store metadata, and the other to store the manifest.
This would allow to build higher level helper function to retrieve data.

Note that this is not a silver bullet: in example 49 of the EPUB spec we still wouldn't be able to retrieve the scheme attribute of the property identifier-type.

Would you accept a PR exploring that direction?