OpenComic puts comic archives, webtoons and ebooks in one Electron window

One library for comic archives, image folders and ebooks

The problem OpenComic addresses is not reading comics, it is reading a mixed shelf. The same person who has a folder of scanned volumes usually also has PDFs and the occasional EPUB sitting beside them, and separate applications mean separate bookmarks and separate ways of tracking progress. OpenComic puts them in one window, and the image side of that window covers 12 formats: `JPG`, `JP2`, `JXR`, `JXL`, `PNG`, `APNG`, `AVIF`, `WEBP`, `GIF`, `SVG`, `BMP` and `ICO`. The archive side covers 11 containers: `RAR`, `ZIP`, `7Z`, `TAR`, `LZH`, `ACE`, `CBR`, `CBZ`, `CBA`, `CB7` and `CBT`. The document side is 2 formats, with one caveat: `PDF` and `EPUB`, with EPUB labelled Alpha. Background music is read from a folder as `MP3`, `M4A`, `MP4`, `WEBM`, `WEBA`, `OGG`, `OPUS`, `WAV` or `FLAC`.

The archive list matters more than the image list. A reader that opens plain zip files and stops there forces you to rename every CBR before filing it. OpenComic takes the container as it ships, which is what a comic scanner produces. Master folders are supported too, so a directory of loose images behaves like one title instead of a hundred separate files.

Scroll, slide and double page change how pages are sequenced

Comic and webtoon pages need different reading logic, and OpenComic exposes both as explicit modes instead of guessing. Manga read mode lays pages out in sequence, while webtoon read mode strips them into a continuous vertical run. Reading then happens in scroll or slide form, and a double page view spreads two pages across the window when the artwork aspect ratio suits it.

Around those 3 axes sit the controls that decide whether a reader stays. Bookmarks and continue reading record a position per title. A floating magnifying glass follows the pointer for dense speech bubbles and fine line work. Tap zones and custom shortcuts cover hardware with no keyboard, and gamepad navigation covers the couch, where a controller is the only input device present. Colour adjustment runs through brightness, saturation, contrast, sepia, negative and invert, and a colorize option turns black and white art into colour.

Image scaling is not left to the graphics driver. The selectable interpolation methods are `lanczos3`, `lanczos2`, `mitchell`, `cubic`, `linear` and `nearest`. That choice is the difference between clean downscales of dense screentone and soft or blocky ones, and having it inside the app means the result does not depend on what the renderer decides.

Remote libraries mount by URL scheme, plus OPDS

Server connection support covers 9 schemes: `smb://`, `ftp://`, `ftps://`, `scp://`, `sftp://`, `ssh://`, `s3://`, `webdav://` and `webdavs://`. A NAS share, a home server reachable over ssh, an S3 bucket and a WebDAV host can all be browsed as folders rather than synced down and mounted locally. That is what separates this reader from a plain image viewer.

OPDS support sits alongside, so a catalogue server speaking the Open Publication Distribution System can feed titles into the same shelves. Organisation leans on favorite labels and custom labels rather than a fixed folder tree, which suits a collection spanning several formats.

Progress tracking goes outward to 4 sites: AniList, MyAnimeList, Mangabaka and Bangumi. What is not documented is how credentials for those services, or for the ssh and S3 connections, are stored, or whether tracked state syncs when the same library opens on a second machine. No configuration file, environment variable or keychain entry is described for any of it, so that behaviour has to be checked by hand before you commit a large library.

Running a development build with Git, Node and NPM

The stated requirements for working on the code are Git, Node and NPM, and 4 commands are the whole sequence:

git clone https://github.com/ollm/OpenComic.git
cd OpenComic
npm install
npm start

The interesting part is what the start script expands to in package.json. It is not a bare Electron launch. It first runs the prebuild step, then starts Electron on the compiled entry point:

"start": "npm run prebuild-start && electron .dist/main.js --no-sandbox",
"prebuild-start": "tsc && node .dist/build.js && node themes/material-design/colors/generate-colors.js && node languages/fill-languages.js"

So a start compiles TypeScript into the dist output, runs the build step, regenerates theme colour definitions with a generator script under the themes tree, and refills the language lists. Themes and translations are generated artefacts rather than hand-edited files, which matters before you change either one. The sandbox flag is hard-coded into the start script, which is ordinary for a development run and says nothing about how the store builds are packaged.

A native zstd dependency that fails with Not exists

The one documented build failure is specific enough to be useful. When a build on Linux or macOS fails with the error `Not exists` , the cause is the native zstd dependency. The repair is a forced reinstall inside that dependency own folder, followed by a normal install in the main folder:

npm install --force

That command belongs inside the directory named `./build/node-zstd-native-dependencies` in the repository layout, which is the clue to how archive formats are handled at all. Native compression code is vendored under the build tree rather than pulled straight from the registry, and that is what makes 7Z, RAR and ACE handling possible. It is also what makes builds specific enough to fail this way.

Build targets are chosen with a placeholder rather than a fixed script name:

npm run build-<buildType>

The available types are nsis and portable on Windows, mac-dmg and mac-pkg on macOS, and deb, rpm, snap, flatpak, appimage and 7z on Linux, each with an arm counterpart such as deb-arm, rpm-arm, appimage-arm and 7z-arm. Finished installers land in the dist folder. The local test chain runs lint, then the unit tests, then a build test, and it is wired into the prebuild script, so it runs before every packaged build.

Four stores, an AUR package and twenty six installers

Distribution is unusually broad for a project of this size. Store listings exist for the Microsoft Store, the Mac App Store, the Snap Store and Flathub. Direct downloads cover Windows as 4 files, with a separate arm64 executable; macOS as dmg, pkg and 7z, each mirrored as an arm64 variant; and Linux as deb, rpm, 7z, tar.gz, snap, flatpak and AppImage, plus a folder-portable archive, with 7 more files for Linux Arm64. Arch users are pointed at an AUR package maintained by someone other than the author.

2 features in the README list are commented out: tab support and multi-window support. They are not shipped, and no note in the repository explains why. Treating that list entry by entry as a wishlist would overstate what the application does today.

The source tree also carries a Pepper & Carrot directory alongside its own fonts, sounds, templates and themes trees. Bundled sample content and first-party assets travel with the code, which is why cloning is the documented route to a development copy rather than installing from a registry.

The manifest runs ahead of the published installer

Every download link on the project page points at v1.6.5, dated 2025-10-31, while package.json already declares 1.6.6, and the last push was on 2026-10-06. The source tree is ahead of what the download page offers, and code is landing well after the newest tagged installer. Anyone reading a version number to decide what they are running should read it from the installed package rather than from the download page.

A second mismatch sits in the build instructions. The documented update step is `npm pull origin master` , which invokes npm rather than git, and npm has no pull subcommand. The intent is a fetch and merge from master, and the branch name is right, but the command as written will not run.

Other manifest details matter to anyone extending it. The entry point is spelled with a leading dot before dist, matching every path in the scripts block, and the project is marked as commonjs despite compiling from TypeScript. The lint configuration is scoped to one directory, scripts, so code outside it is not checked by the default test chain.

Where OpenComic is the wrong tool

The clearest wrong-tool case is scripting. Everything OpenComic offers is reached through a window: labels, modes, interpolation methods, the magnifying glass, gamepad navigation. The scripts block contains build, test, lint and rename targets, and nothing that opens a file, converts an archive or queries the library. If the requirement is batch conversion, scheduled sync or a headless catalogue, this repository does not provide it, and installing the desktop application will not get you there.

Second, EPUB is the weak spot in an otherwise broad format story. The project labels it Alpha, which is the project own word for unfinished, and it sits in the same list as PDF with no further qualification. A library where ebooks matter as much as comics has a better tool for that half.

Third, tab support and multi-window support are commented out. Readers who keep a comic and an ebook open side by side will look for both and not find them. Those 2 cases, plus the Alpha status of EPUB, are the boundaries to check against your own shelves before installing.

Editorial conclusion

OpenComic earns a place on the desktop of anyone whose shelves mix comic archives with ebooks and PDFs, and who wants those remote server mounts inside the same library view. It does not earn one for web publishing, catalogue scraping or scripting, because the repository exposes a GUI application with no command line interface of its own. Before installing, check the build type you need against the list of targets, and read the zstd dependency note if a Linux or macOS build fails with a Not exists error.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. ollm/OpenComic on GitHub
3. Project website
4. README
5. Releases