epublift — EPUB toolbox: modernise, shrink, kepub, validate, repair, archive

[Kayadelenium]

Three replies here came in while I was working on the release. Here are my answers.

Originally Posted by PeterT

Any plans on publishing epublift to cargo.io? My approach to all of you tools is doing a cargo build rather than a download of a precompiled binary

Yes, I will publish it on crates.io, as epubveri and epubsana already are. Until then it installs straight from the repository:

cargo install --locked --git https://github.com/ePubLift/epublift --tag cli-v3.3.0 epublift --features epub34,metadata,pdf-ocr,markdown,validate

Keep the features: they are what the release binaries are built with. Without validate there is no check command, and without metadata no ISBN lookup.

Originally Posted by JSWolf

What would really help to stop the complaints is to make the defaults to keep the existing images and ZIP format for the container

The container part is already the case. Optimize has only ever written an ordinary ZIP. The Zstandard container is an experiment that is not in the released program or on the web page at all. The one place Zstandard is used is Archive, which writes a separate .eparc file for storage, and only when you ask for it.

The images part: you are right, and I am changing it. Keep original will become the default, on the web page and on the command line, and WebP will be something you choose. It will come together with the conversion fixes.

Originally Posted by KevinH

So just because the Epub spec supports a format, do not expect the publishing community to start throwing away gif, jpeg and png any time soon.

I don't expect them to. epublift is not aimed at publishers; it works on books readers already have. That is also why EPUB 3.4 output, with AVIF or JPEG XL images, is only there if you ask for it (--target 3.4), and once the new default is in, WebP will be opt-in too. On JPEG XL in Chrome, that changed this week: Chrome 155 ships JPEG XL decoding, using jxl-rs, a decoder written in pure Rust. Readers built on Chromium will only get it as they update, though, and e-ink devices take longer still, so your point about how slowly publishing moves stands.

[JSWolf]

Oh and can you build in options to convert from Webp, AVIF, and JXL into JPG or PNG? If ePub start being in the wild with these new image formats, a lot of people won't be happy. But that will be happy if they can convert the images to a format that can be used.

[Kayadelenium]

Yes, I have an idea for a tool that converts between EPUB3 and EPUB2 and allows you to select image formats during the process. Since I haven't finished the core tasks yet, I can't attend to the other work.

- Fixing epubveri errors
- Writing plugins for epubsana
- Developing kepubverto and then writing its plugins
- ....

Phew Captain... there is so much work to do.

[JSWolf]

Originally Posted by Kayadelenium

Yes, I have an idea for a tool that converts between EPUB3 and EPUB2 and allows you to select image formats during the process. Since I haven't finished the core tasks yet, I can't attend to the other work.

- Fixing epubveri errors
- Writing plugins for epubsana
- Developing kepubverto and then writing its plugins
- ....

Phew Captain... there is so much work to do.

That's all wrong. The idea is to convert the images regardless of the ePub version. Most programs that handle ePub3, won't handle those formats. So allow conversion regardless of the ePub version. I don't want an ePub3 don't work because the image format(s) are not supported.

Just allow image conversion without converting the ePub in any other way.

And if you want the ePub to remain as ePub3 but be backwards compatible, these image formats, need to be converted in place and the OPF updated.

The thing is, these new (new to ePub) image formats should never have been sanctioned. The W3C are becoming really stupid (IMHO).