url-to-epub VS zimit

I do a lot of this work[3] (web to documents) and it's interesting to see other approaches. The medium image problem is something I've faced as well, but never got around to fixing. I'm planning to get a Remarkable soon, so will definitely be trying this out.

My personal solution has been https://github.com/captn3m0/url-to-epub/ (Node/readability), which I've tested against the entirety of Tor's original fiction collection[0] where it performs well enough (I'm biased). Another tool that does this beautifully well is percollate[1], but it doesn't give enough control of the metadata to the user - something I really care about.

I've also started to use rdrview[2], which is a C-port of the current Firefox implementation of "reader view". It is very unix-y, so it is easy to pipe content to it (I usually run it through tidy first). Quite helpful in building web-archiving or web-to-pdf or web-to-kindle pipelines easily.

[0]: https://www.tor.com/category/all-fiction/original-fiction/

[1]: https://github.com/danburzo/percollate

[2]: https://github.com/eafer/rdrview

[3]: https://captnemo.in/ebooks/

There are clearly similarities between the two, given that Kiwix put resources into making WARC content available in ZIM archives (i.e. Zimit-style ZIMs, created with the Zimit scraper and warc2zim backend). But as u/IMayBeABitShy said, the ZIM specification focuses on providing a highly compressed container that is readable on-the-fly (i.e. by decompressing only the needed content to show an article), whereas WARC, or rather the compressed version WACZ, is merely a zipped version of the WARC data (request headers and responses). It is also readable on-the-fly, but compression will not be as optimal as the zstandard compression used by modern ZIM archives.

I'm looking at making my own ZIM though not sure the best way to go about it. I've seen zimit on Github and the mwoffliner on Github too.

You would have more chances at getting a technical reply to your technical issue by hitting https://github.com/openzim/zimit/issues I believe

The zimit readme says it uses /output as the default directory, so we can use that as the name for our docker's volume.

Zimit. This tool allows you to convert an existing website into an offline ZIM archive. https://hub.docker.com/r/openzim/zimit

which worked quite well for most sites, but still very far from a general-purpose solution.

There is also more powerful/general-purpose scraper that generates a ZIM file here: https://github.com/openzim/zimit

It would be really nice to a "common" scraper code base that takes care of scraping (possibly with a real headless browser) and outputs all assets as files + info as JSON. This common code base could then be used by all kinds of programs to package the content as standalone HTML zip files, ePub, ZIM, or even PDF for crazy people like me who like to print things ;)

There is a limit at 1,000 items for each zim because we don’t want to DDoS unsuspecting websites with requests; and also would not be able to afford the bill If it becomes as popular as we think it will be. But since this is free software, you can obviously cut the middleman by copying, studying, modifying and redistributing the code that can be found here: https://github.com/openzim/zimit or contact us directly and get the full thing for a small fee (tbd, but this should not be a blocker for legitimate uses).

Documentation is available at github.com/openzim/zimit and github.com/kiwix (there's a repo for each platform, kiwix-serve and android are the ones to look at atm for integration of service workers)