lise-henry / epub-builder Goto Github PK

A number of* EPUB's metadata attributes allow repeated elements, for example to define multiple authors:

<dc:creator opf:role="aut">Terry Pratchett</dc:creator>
<dc:creator opf:role="aut">Stephen Briggs</dc:creator>

and multiple genres:

<dc:subject>Fantasy</dc:subject>
<dc:subject>Humour</dc:subject>

(or multiple tags, common in web fiction and fanfiction)

However, this library only allows one instance of each. It's not clear to me what use there is for repeating some of the elements (different languages?) but I checked ebooks I own and found that the following are commonly repeated:

It would be useful for this library to allow this.

*: See § 3.4.3 Metadata and particularly § 3.4.3.3 DCMES Optional Elements

hi!

error-chain is no longer maintained and difficult to use with modern error handling libraries.

Could you replace it with a more modern one, like anyhow?

Thanks! :)

Hi there

I've this https://github.com/rgarrigue/songbook which build an epub through mdbook + mdbook-epub plugin, plugin which use this crate. The resulting epub (you can download it in my repo Releases) is seen a "Unauthorized to read due to Adobe DRM" (unaccurate French to English translation) by my Kobo H2O eReader.

I've reported it there Michael-F-Bryan/mdbook-epub#28, and they adviced me to drop a word here too.

I don't know anything about epub & so on, but feel free to link me some epub to check on my eReader if you want to try possible issues.

I am trying to add an image to my EPUB by following what's described on README but I cannot seem to pull it off.

let dummy_image = "Not really a PNG image";
(...)
        .add_resource("some_image.png", dummy_image.as_bytes(), "image/png")?

I am miserably failing to figure out the proper way to load the image so that epub_builder can load it into the EPUB.
I use calibre's edit book to check the file and it finds the file but it complains that it's "not a valid image".

I tried loading my image with things like:
let img = ImageReader::open("images/default-vpc-diagram.png").unwrap();

let img = image::open("images/default-vpc-diagram.png").unwrap();

let filename = "images/default-vpc-diagram.png";
let mut img = File::open(&filename).expect("no file found");                                                                                                                                                 
let metadata = fs::metadata(&filename).expect("unable to read metadata");
let mut buffer = vec![0; metadata.len() as usize];
img.read(&mut buffer).expect("buffer overflow");

let img = fs::read(filename).expect("Unable to read file");

I know for a fact my Rust knowledge is limited (very) and I'm failing to see something obvious. Still it would be great to have a more specific case on how to load those images on the README.

Thanks in advance!

Since 1e3af55, epub_builder::Error is no longer available for using in downstream project. Specifically mdbook-epub is using epub_builder::Error to define a transparent error variant of thiserror. Without that, it would need to introduce eyre as a dependency IIUC and have some changes to upgrade to next release.

Could you consider re-exporting eyre::Report as Error for compatibility? Or give guidance to migrate?

Edit: see also Eyre's doc

We recommend users do not re-export types from this library as part their own public API for libraries with external users.

In the XML 1.0 specification, there're no optional spaces around the equal sign that separate an attribute name from its value.

I noticed when generating eBooks with this library, that my eBook reader expect the metadata section for the cover image in content.opf to look like

<meta name="cover" content="cover-image" />

instead of the at the moment generated:

<meta name="cover" content="path/to/image.jpeg" />

(My eBook reader does not show a cover image with the current meta data, but the book is still usable)

this would be easy to fix in line 390 in epub.rs

Note: I don't have access to the epub spec so this 'issue' is based on my empirical observations and might not be an issue with actual epub spec compliance

On the page https://crates.io/crates/epub-builder/0.7.4 specified publish date 2023-08-11 and these crate doesn't content last change.
Please check it out.

It seems that after disabling 'deflate' feature for zip dependency (7c66dfd), all generated epubs are not compressed at all.

If i add direct dependency in my project, with "deflate" feature
zip = { version = "0.5", optional = true, default-features = false, features = ["time", "deflate"] }
zip compression starts working.

Zip files should always use forward-slashes in paths (see e.g. this bug report for a citation).

In three different places in epub.rs, a path is created using Path::new("OEBPS").join(...), which uses the default path item separator for the platform. On Windows, this is a backslash.

ZipCommand handles this correctly, but ZipLibrary passes the path on verbatim. The resulting EPUB fails validation at http://validator.idpf.org/ because of files mentioned in the manifest that it can't find (e.g. OEBPS/foo.html) and files that it can see but aren't in the manifest (e.g. OEBPS\foo.html).

A simple solution that I've tested locally is changing https://github.com/lise-henry/epub-builder/blob/master/src/zip_library.rs#L59 to

let file = format!("{}", path.as_ref().display()).replace('\\', "/");

which feels like a hack, but works. I suspect a proper fix would involve also fixing up paths added to the manifest, in case a user adds an EpubContent with a \ in it.

Hey,
I'm creating multiple ePubs at once and thought about using async rust for file I/O but realized that this crate doesn't support async read and write.

Would it even be feasible sense to add that?

If so, I'd try implementing it myself.

Hello.

1. I suggest using the function new instead of the function epub_version for set epub version object's EpubBuilder.
2. I suggest using default EPUB 3.0.1 instead of EPUB 2.0.1.

I can send patches if you don't mind.

It's been about a year since 0.5. Are there other changes you're planning before 0.6? I currently need the fact that time has been updated so this can be compiled to wasm. Currently I'm pinned to a random githash, but would love to pin to 0.6 and was curious if there was a timeline or other aspects you wanted to finish before cutting.

Thanks for the super useful library!

I generated the example book by running:

cargo run --example test > test.epub && open test.epub

Trying to open the example book in MacOS Books, I see the following error:

I can tell from the splash screen and table of contents that the MacOS Books application is able to understand a lot of the structure of the book.

If the README example isn't intended to produce a 100% valid book, what do you think of adding a smaller example that is guaranteed to always produce a valid book as output? I would be happy to take a stab at this.

zip-rs/zip-old#151

As discussed in the issue, zip-rs was adding a comment that caused epub files to have trouble. This issue is now fixed in the git repository but is still not live on cargo.io (https://crates.io/crates/zip).

When the new version is available on cargo.io (Probably going to be v0.5.7), we should upgrade to fix the issue in this repo.

At the moment, when generating the inline TOC, chapter titles are stripped of HTML tags using the html2text crate.
This however makes it impossible to use certain titles (e.g. we can't have a chapter named "the <code> tag") and creates an invalid "toc.ncx".
Moreover, using html2text to escape the title can turn valid titles into invalid ones; this happens when the title contains HTML entities (e.g. &), which get converted into the relative character.

The solution could be to use the html_escape crate to escape the title, either using it after html2text or in place of it. If we replace html2text there would be no limitations to the chapter titles, however the behavior would be different than before for titles that contain HTML tags. Using both the crates would limit the possible titles, but still fix the invalid TOC and maintain the current behavior.

Personally I would replace the html2text and use only html_escape, since this would also reduce the dependencies quite a bit.

Once what to do is decided I can create a pull request