hey! I'm the author of Honzo, an open-source binary ebook format (Apache-2.0). I noticed this when browsing the internet ages ago, and now I (finally lollll) shipped v0.1.0!!! So this might be a bit rambly, but I wanted to talk about it and get your opinion on anything the future org.nisoku.comic EXTRA chunk will have!!!!
what Honzo is
Honzo is a chunked binary format for ebooks. think "what if EPUB was a flat binary with a TOC instead of a ZIP full of XML."
the format uses a HEAD | TOC | DATA | EXTRA | META layout where each section has a specific job.
content lives in typed chunks (CHAP, IMG_, FONT, CSS_, COVR, MATH, etc.), metadata is MessagePack, and the EXTRA section holds namespaced extensions.
it already supports LZ4 compression, AES-256-GCM encryption, search indexes, sync tracks (audio/video/page mapping), annotations, and print page mapping. the core library is in Rust and I added C/C++ and WASM/TypeScript bindings, plus an EPUB/PDF/MOBI converter!
Why am i talking about it?
the EXTRA chunk system is where this gets interesting for comics. EXTRA entries are namespaced binary blobs (MessagePack serialized) that any application can read or ignore. the format already has org.nisoku.anno, org.nisoku.drm, and org.nisoku.sync namespaces. adding org.nisoku.comic (with the comic specifc fields in ComicInfo.xml) would be straightforward and be so cool!!!!
here's what I'm planning for comic support:
- CBZ converter that reads ZIP archives, extracts images, parses ComicInfo.xml, and builds a Honzo file with proper metadata mapping
org.nisoku.comic EXTRA chunk carrying the stuff ComicInfo has that general ebook metadata doesn't: AlternateSeries, Teams, SeriesGroup, Page.Type per image, story arcs, age ratings- extended HonzoMeta fields for Count/Volume on series info, Characters/Locations, monochrome hints, community ratings
- manga mode in the reader demo already exists (vertical scroll with gapless/webtoon mode, zoom controls, per-page tracking)
the format naturally handles the comic use case because images are first-class chunks (IMG_, COVR) with per-chunk compression, CRC32 verification, and alt text. a 200-page manga is just 200 IMG_ chunks with a PMAP for page numbering.
what I'd love feedback on
- would it make sense to align the comic EXTRA namespace with the Anansi target data model instead of inventing yet another schema? However, chunked binary is a very different format than ZIP-based existing stuff (well DjVu actually is kinda similar, but I never see it much :( anywhere)
- the Anansi model separates WHAT (data model) from HOW (container format). Honzo is a HOW. could it serve as a container format candidate, or is the scope too different?
- are there fields in the Anansi UML data model that don't map cleanly to Honzo's chunk/metadata architecture? Or fields y'all want?
Please tell me anything lol, I would love to help!!!!!!
hey! I'm the author of Honzo, an open-source binary ebook format (Apache-2.0). I noticed this when browsing the internet ages ago, and now I (finally lollll) shipped v0.1.0!!! So this might be a bit rambly, but I wanted to talk about it and get your opinion on anything the future
org.nisoku.comicEXTRA chunk will have!!!!what Honzo is
Honzo is a chunked binary format for ebooks. think "what if EPUB was a flat binary with a TOC instead of a ZIP full of XML."
the format uses a
HEAD | TOC | DATA | EXTRA | METAlayout where each section has a specific job.content lives in typed chunks (CHAP, IMG_, FONT, CSS_, COVR, MATH, etc.), metadata is MessagePack, and the EXTRA section holds namespaced extensions.
it already supports LZ4 compression, AES-256-GCM encryption, search indexes, sync tracks (audio/video/page mapping), annotations, and print page mapping. the core library is in Rust and I added C/C++ and WASM/TypeScript bindings, plus an EPUB/PDF/MOBI converter!
Why am i talking about it?
the EXTRA chunk system is where this gets interesting for comics. EXTRA entries are namespaced binary blobs (MessagePack serialized) that any application can read or ignore. the format already has
org.nisoku.anno,org.nisoku.drm, andorg.nisoku.syncnamespaces. addingorg.nisoku.comic(with the comic specifc fields inComicInfo.xml) would be straightforward and be so cool!!!!here's what I'm planning for comic support:
org.nisoku.comicEXTRA chunk carrying the stuff ComicInfo has that general ebook metadata doesn't: AlternateSeries, Teams, SeriesGroup, Page.Type per image, story arcs, age ratingsthe format naturally handles the comic use case because images are first-class chunks (IMG_, COVR) with per-chunk compression, CRC32 verification, and alt text. a 200-page manga is just 200 IMG_ chunks with a PMAP for page numbering.
what I'd love feedback on
Please tell me anything lol, I would love to help!!!!!!