Calibre replacement considerations

  1. software
  2. desktop
  1. Summary
  2. Problems with Calibre
  3. What does Calibre do anyways
    1. ebook viewer
    2. ebook editor
    3. File converter
    4. Collection browser
    5. ebook web server
      1. calibre webserver setup
      2. AnthoLume quick test
      3. Kavita quick test
    6. Metadata editor
    7. Device synchronization
    8. RSS reader
    9. Other functionality and future thoughts

Summary

TL;DR: I'm considering replacing those various Calibre compnents with...

My biggest blocker that don't really have good alternatives are:

See below why and a deeper discussion on all the features.

Problems with Calibre

Calibre is an amazing software: it allows users to manage ebooks on your desktop and a multitude of ebook readers. It's used by Linux geeks as well as Windows power-users and vastly surpasses any native app shipped by ebook manufacturers. I know almost exactly zero people that have an ebook reader that do not use Calibre.

However, it has had many problems over the years:

Update: a previous version of that post claimed that all of Calibre had been removed from Debian. This was inaccurate, as the Debian Calibre maintainer pointed out. What happened was Calibre 4.0 was uploaded to Debian unstable, then broke because of missing Python 2 dependencies, and an older version (3.48) was uploaded in its place. So Calibre will stay around in Debian for the foreseeable future, hopefully, but the current latest version (4.0) cannot get in because it depends on older Python 2 libraries.

The latest issue (Python 3) is the last straw, for me. While Calibe is an awesome piece of software, I can't help but think it's doing too much, and the wrong way. It's one of those tools that looks amazing on the surface, but when you look underneath, it's a monster that is impossible to maintain, a liability that is just bound to cause more problems in the future.

What does Calibre do anyways

So let's say I wanted to get rid of Calibre, what would that mean exactly? What do I actually use Calibre for anyways?

Calibre is...

ebook viewer

Calibre ships with the ebook-viewer command, which allows one to browse a vast variety of ebook formats. I rarely use this feature, since I read my ebooks on a e-reader, on purpose. There is, besides, a good variety of ebook-readers, on different platforms, that can replace Calibre here:

See also the pdf-viewer metapackage for other ideas here.

ebook editor

Calibre also ships with an ebook-edit command, which allows you to do all sorts of nasty things to your ebooks. I have rarely used this tool, having found it hard to use and not giving me the results I needed, in my use case (which was to reformat ePUBs before publication).

For this purpose, Sigil is a much better option, now packaged in Debian.

There are also various tools that render to ePUB: I often use the Sphinx documentation system for that purpose, and have been able to produce ePUBs from LaTeX for some projects.

File converter

Calibre can convert between many ebook formats, to accommodate the various readers. In my experience, this doesn't work very well: the layout is often broken and I have found it's much better to find pristine copies of ePUB books than fight with the converter.

There are, however, no alternatives to Calibre for this functionality, unfortunately.

Update: someone courageously took it upon themselves to take the best out of Calibre's ebook-convert, rip out all the un-needed stuff, and make it shine. See the ebook-converter project, untested.

Collection browser

This is the main functionality I would miss from Calibre. I am constantly adding books to my library, and Calibre does have this incredibly nice functionality of just hitting "add book" and Just Do The Right Thing™ after that. Specifically, what I like is that it:

Calibre is, as far as I know, the only tool that goes so deep in solving that problem. The Liber web server, however, does provide similar search and metadata functionality. It also supports migrating from an existing Calibre database as it can read the Calibre metadata stores. When no metadata is found, it fetches some from online sources (currently Google Books).

One major limitation of Liber in this context is that it's solely search-driven: it will not allow you to see (for example) the "latest books added" or "browse by author". It also doesn't support "uploading" books although it will incrementally pick up new books added by hand in the library. It somewhat assumes Calibre already exists, in a way, to properly curate the library and is more designed to be a search engine and book sharing system between liber instances. This is something that trantor might be better at, although it doesn't use the Calibre database, so it might not have as good metadata...

This also connects with the more general "book inventory" problem I have which involves an inventory physical books and directory of online articles. See also firefox (Zotero section) and bookmarks for a longer discussion of that problem.

Finally, it could simply be that a file browser could act as a collection browser, as long as book covers would be shown in parent folders. KDE's Dolphin actually shows a preview of images inside a folder, but only one layer deep, so it actually doesn't really work for Calibre-styled libraries, where each book has its own directory. Thunar (XFCE's) doesn't seem to do previews correctly either.

And this of course overlaps with another functionality that Calibre provide, which is that it's also... a web server!

See below for web-based collection browsers.

Update: citadel looks really promising, Rust backend with JS frontend. There's about 4 or 5 different frameworks in there so it will be hellish to package. A Flatpak maybe? Blog post, HN.

ebook web server

Calibre can indeed also act as a web server, presenting your entire ebook collection as a website. It also supports acting as an OPDS directory, which is kind of neat. There are, as far as I know, no alternative for such a system although there are servers to share and store ebooks, like Trantor or Liber.

Unfortunately, neither of those support OPDS, which is too bad: that protocol is quite useful to browse books on the fly from hacked Kobo readers (running Koreader, but not Plato) or Android devices (running Document Viewer or Koreader)... There is an OPDS test server, see also my 2016 analysis.

Other alternatives include a web interface called calibre-web that seems independent from the Calibre project and talks directly to the database using SQLAlchemy. It does use calibre components to convert books but it might be an interesting alternative to the web interface shipped with Calibre.

AnthoLume, kavita (C#), librum (dotnet), storyteller kiosk, readarr ("arr" stands for "aaargh C#/Windows again!") and Ubooquity (... Java) are things as well, none of which are packaged in Debian. (What is it with e-book webservers being written in C#?!)

calibre webserver setup

I ended up setting up calibre on the server side of things to have an OPDS directory to more easily transfer books from my e-reader, now that I have an Android tablet (running "Document Viewer" or "Koreader", both of which support OPDS), or Koreader on my Kobo (which works much better than before, thanks to NickelMenu. I setup the service using this .service file:

[Service]
Type=simple
User=calibre-sandbox
Group=media
# this exposes the service to local users, which isn't great. socket activation
# would be better, but is not documented upstream and, well, it's only books and
# /srv/books is readable anyways..
ExecStart=/usr/bin/calibre-server --disable-fallback-to-detected-interface --listen-on 127.0.0.1 --port 4341 /srv/books

[Install]
WantedBy=multi-user.target

The server is made publicly visible with authentication (because I don't trust calibre's builtin auth) thanks to this Apache configuration file:

<VirtualHost *:80>
    ServerName calibre.anarc.at
    Redirect / https://calibre.anarc.at/
    DocumentRoot /var/www/html/
</VirtualHost>

<VirtualHost *:443>
    ServerName calibre.anarc.at
    Use common-letsencrypt-ssl calibre.anarc.at
    DocumentRoot /var/www/html/
    AllowEncodedSlashes On
    ProxyPreserveHost On
    ProxyPass /.well-known/ !
        # 43 41 is ASCII hex for C A (L I B R E)
        ProxyPass / http://127.0.0.1:4341/
        ProxyPassReverse / http://127.0.0.1:4341/

        <Location />
        AuthType Basic
        AuthName "Restricted Content"
        AuthUserFile /etc/apache2/htpasswd.calibre
        Require valid-user
    </Location>
</VirtualHost>

Calibre is installed through Flatpak because that version is more up to date in Debian (although for the server side of things that shouldn't really matter). I tried to make systemd detect changes to the database and reload the service, but it failed, so maybe i'll need to look at another filesystem monitoring tool.

If you get a weird error about "Failed to communicate", it might be because the database is not writable by Calibre. Here I had to make it owned by a shared group and writable:

chown :media metadata*
chmod g+w metadata*

I also added that in .git/hooks/post-checkout for my future self, although git-annex might overwrite that eventually...

AnthoLume quick test

I tested AnthoLume briefly, mainly because it is not written in C#. It's promising. It can manage EPUB files (and not, e.g. PDFs or MOBI files) and can be used to read books in a web browser.

I haven't been able to import my existing library and only imported one book from Standard Ebooks as a test. It found the book title, author and a one-line summary, but not a proper cover. It did manage to find extra metadata online (a longer summary, a cover and ISBN), but after quite a few clicks. Each book has to be imported individually.

It has a plugin for KOReader that behaves like a koreader sync server that the normal kosync plugin uses. Files are stored in a flat tree structure, and data is stored in a SQLite database:

anarcat@angela:antholume_data$ find -type f
./documents/Agatha Christie - The Mysterious Affair at Styles [9333dc7f73125c9a96ded94794012294].epub
./antholume.db
./covers/9333dc7f73125c9a96ded94794012294.jpg
./antholume.db-wal
./antholume.db-shm

Kavita quick test

I did the same with Kavita: run the Docker container, open in a web browser, etc. That worked a bit better: Kavita could import my existing collection. It even did so fairly quickly: it scanned my 700+ book directory in about 10 minutes, and during that whole time the UI was working, visually adding books in real time and showing progress information:

[Kavita] [2023-11-19 03:56:56.280 +00:00  56] [Information] API.Services.Tasks.ScannerService [ScannerService] Finished library scan of 786 files and 682 series in 383606 milliseconds for books

Nice.

It found embedded book covers, titles, authors, overall metadata support seems pretty good. It's unclear if it can fetch metadata online however, and I suspect a good chunk of the metadata might also come from Calibre's OPF files.

Indeed, in the EPUB documentation they explain that:

Calibre eBook Management software can be used to edit epub metadata to include Series, Volume, and Title so that series with multiple books parse correctly into the same series.

... almost made it. I also believe it fails to detect series from Calibre properly: I have a few books where I deliberately and painstakingly set that up in Calibre and it didn't work properly in Kavita.

The online book reader is excellent. You can modify the orientation, font, margins, and supports the table of contents. It supports bookmarks which also double as annotations.

At first, all books appear as individual series which is a bit maddening. If you can't figure out series, just show me the books, you know? The other UX problem I found is that, inside a book, clicking an author just brings you back to the main book listing, without selecting said author as you might expect.

Naturally, fields like "date added" also do not get carried over from Calibre, which is a bit of a shame as that's pretty much the only way I can figure out what I'm going to read next nowadays.

It's open core, with something called Kavita+ that adds features to paying, monthly, customers. Interesting features like Kobo Progress Sync and "Non-Manga Book Support" (?!) are only in the proprietary version.

Kavita supports EPUBs, PDFs, "Manga" and "Comics" (which seem to both be .cbz files and "raw images" (within a folder). It also has extensive OPDS and OPDS-PS support (originally created by Ubooquity). It supports automatic library rescans. More information about features here.

All in all, quite interesting, but the lack of online metadata support is a blocker. The proprietary bits also make me not really interested in contributing back to the project.

It did lead me to discover komga as another possible software, but that seems focused exclusively on mangas and comics.

Metadata editor

The "collection browser" is based on a lot of metadata that Calibre indexes from the books. It can magically find a lot of stuff in the multitude of file formats it supports, something that is pretty awesome and impressive.

For example, I just added a PDF file, and it found the book cover, author, publication date, publisher, language and the original mobi book id (!). It also added the book in the right directory and dumped that metadata and the cover in a file next to the book. And if that's not good enough, it can poll that data from various online sources like Amazon, and Google books.

Maybe the work Peter Keel did could be useful in creating some tool which would do this automatically?

Keel's work relies on the aging epub-tools suite which hasn't seen a release since 2012, but does offer some sort of parsing of ePUBs. For example, the einfo command can extract the author and title of a book and could be used to reproduce the "put file in the right directory" part of what Calibre is doing here.

The ebooklib library is another piece of code that might be usable to generate our own importer, as it can parse (and edit!) metadata from books.

Liber can also fetch metadata from Google books, but not interactively. Citadel also seems capable of getting (or at least editing) metadata.

So I still use Calibre for importing books, but mostly rely on Koreader to browse the library, basically using the folder hierarchy with modification timestamps as a guide.

I rarely use Calibre to actually edit the metadata, although it does happen when the author, title, or collection is really mangled. I do miss a way to regroup books by collections sometimes, but can't help but think this could be done by folder / book naming or some out of band metadata.

I have recently figured out that my Calibre workflow could be simply:

calibredb add <file> ...

... to add multiple files to the library automatically, as separate books. Or, to add multiple formats of the same book:

calibredb add -1 <directory>

The flag -1 being a shortcut to --one-book-per-directory.

The fetch-ebook-metadata command can also be used to pull metadata from online servers, particularly interesting for its --cover option if the above files don't have proper covers, but it can also pull everything else. Downside: that doesn't get saved to Calibre's database, but it can save a OPF file that can then be fed into calibredb set_metadata <book_id> <opf_file>.

I also started implementing my own importer in import-book but it's just a bad first prototype, probably to be discarded if we're serious about this. It could start by being a wrapper for Calibre's above function, progressively replacing each of them by our own code until we're satisfied.

Or we can just keep using Calibre.

Another big problem I have with Calibre right now is that it enforces this Author/Title/Title.epub folder structure which is really heavy and annoying. It feels like iTunes. I have 355 authors in my collection here and 952 books (or at least 952 second-level folders), so the Author/Title distinction is really not helping much: a flat hierarchy of Author - Title.epub would really work just as well, and would make the book collection much easier to browse using standard tools (e.g. Koreader would render it much more nicely).

Compare, for example, before:

and after flatting:

Now, I cheated a little bit there as I don't show the other Ada Palmer books, for which Koreader somehow can't generate a cover for (which is a problem!) and I deleted the cover.jpg that Calibre adds everywhere which would otherwise double the listings everywhere. (But I'm considering ditching those files anyways, since they clutter everything and needlessly inflate the library.)

But this is something the Calibre author has been completely inflexible on since basically forever:

If you are still not convinced, then I’m afraid calibre is not for you. Look elsewhere for your book cataloguing needs. Just so we’re clear, this is not going to change. Kindly do not contact us in an attempt to get us to change this.

... which is a recurring pattern of "my way or the highway" with this software. Totally within their right of course, but exactly the kind of things that make me want to look elsewhere.

In any case, if we're going to ditch Calibre, this would be the procedure:

rm */*/cover.jpg # remove all covers
# rename all actual book files without the directories, keeping extension
rename 's,([^/]*)/([^/]*)/.*-.*(\....),$1 - $2$3,' */*/*
# rename remaining files, should just be metadata.opf
rename 's,([^/]*)/([^/]*)/metadata.opf,$1 - $2.opf,' */*/*
# remove empty directories, if this fails, we forgot some
rmdir */*

Device synchronization

I used Calibre to synchronize books with an ebook reader (typically a Kobo). It can automatically update the database on the ebook with relevant metadata (e.g. collection or "shelves"), although I did not really use that feature. I did like to use Calibre to quickly search and prune books from by ebook reader, however.

I considered using git-annex for this, however, given that I already use it to synchronize and backup my ebook collection in the first place...

But more recently I started just synchronising my entire book collection with Syncthing. The collection is small enough to fit on a SD card if I judiciously ignore some parts with a local .stignore file. The details of that setup are in this blog post.

RSS reader

I used this for a while to read RSS feeds on my ebook-reader, but it was pretty clunky. Calibre would be continously generating new ebooks based on those feeds and I would never read them, because I would never find the time to transfer them to my ebook viewer in the first place. Instead, I use a regular RSS feed reader.

I ended up writing my own (feed2exec) and when I find an article I like, I add it to Wallabag which gets sync'd to my reader using wallabako, another tool I wrote.

Other functionality and future thoughts

Note that I might have forgotten functionality in Calibre in the above list: I'm only listing the things I have used or am using on a regular basis. For example, you can have a USB stick with Calibre on it to carry the actual software, along with the book library, around on different computers, but I never used that feature.

So there you go. It's a colossal task! And while it's great that Calibre does all those things, I can't help but think that it would be better if Calibre was split up in multiple components, each maintained separately. I would love to use only the document converter, for example. It's possible to do that on the commandline, but it still means I have the entire Calibre package installed.

Maybe a simple solution, from Debian's point of view, would be to split the package into multiple components, with the GUI and web servers packaged separately from the commandline converter. This way I would be able to install only the parts of Calibre I need and have limited exposure to other security issues. It would also make it easier to run Calibre headless, in a virtual machine or remote server for extra isoluation, for example.

Unfortunately, Calibre's design doesn't lend well to this. Everything is bundle up together and what seem to be independent binaries (say, ebook-meta) are really stub entry points to the much larger Calibre Python modules.

Update: this post generated some activity on Mastodon, follow the conversation here or on your favorite Mastodon instance.

RSS
comment 1

Calibre is a complex piece of machinery, and it's therefore buggy.

So you're going to replace it with 6 or 7 pieces of machinery, some of them complex, some of them buggy, some of them now that well maintained.

Comment by Carlos —
maybe

maybe you're right. maybe the result will be too complex and buggy and will not be useful. but the reality of the problem now is that Calibre 4.0 is not going to make it to Debian until it's ported to Python 3. And even if it does, I have enough serious concerns about the security of Calibre to never want to use it again. It would need to go through a full audit, with a significant overhaul of its design and architecture, for me to ever trust it again.

I strongly doubt that the tools I have enumerated in my review will be as buggy and insecure as Calibre. Maybe I'll be proven wrong, but so far, many of those tools have proven to be well maintained and perform extremely well.

I feel it's definitely worth a try.

(I am also unsure as to which package you're refering to when you say "now that well maintained"...)

Comment by anarcat —
already used tools

Another thing to understand about this list of tools is that I already use a lot of those. I already:

  • use Sphinx and Sigil to work with eBooks
  • manage and synchronize my library across multiple devices with git-annex
  • read PDFs with Evince (which Atril is derived from)
  • read RSS feeds with another feed reader

It's not like I'm hell-bent on causing the Calibre people pain here. :) It's just that I found too many problems with the software, and now it's possibly going away so I'm looking at alternatives. I thought I could share this with the community, if you don't like the answers, you're free to talk a walk elsewhere and keep on happily using Calibre, blissfully unaware of any problems I might be ranting about here. :p

Comment by anarcat —
comment 4

For okular on Debian, the epub plugin is in the okular-extra-backends package. Can't tell you if it works fine (I don't use ebooks) but I can open epubs.

Comment by tonton —
git-annex metadata

I've often thought that one of these days I should write a script that would parse through Calibre's metadata.opf file for each book and add it to the git-annex metadata of the ebook file. This would allow you to do all sorts of browsing, filtering and searching with git-annex's own powerful tooling, which is probably better than anything we could do today with Calibre itself (assuming you don't need a GUI).

But the problem is getting the metadata in the first place which, as you pointed out, is one of the things that Calibre does pretty well. For my video collection, I wrote metamovie to pull down metadata of movies and television shows from IMDB and store it as git-annex metadata. I suspect that it wouldn't be too difficult to hack together a similar script, using something like Google Books or Goodreads as the source. The difficult part is probably the search. With movies there is a single canonical entry, but with books you may have dozen of editions. Choosing the right one (or the one with the richest data, even if it doesn't exactly match your edition) could be a bit tricky.

Comment by Pig Monkey —
Another perspective

Hi,

Thanks for writing this. So I have a Kindle, which doesn't support ePub at all. I have used Calibre at times over the years; the organization it imposes over a collection is very good, but the formatting changes in makes and the things it does during "synchronization" are not. I have mostly stopped using it because it is too cumbersome, though I do invoke ebook-viewer manually from time to time. Critically, though, Calibre does provide mobi-to-epub conversion and better support for the newer formats Amazon keeps burdening us with than most other tools. So if I were to switch to another tool, I'd have to start with Calibre and the other tool would be useful only for reading things on a PC screen (a thing I only do occasionally with ePub-type books) and not at all useful for reading things on my Kindle (a thing I do often).

This is not a defense of Calibre; I know of its quality problems first-hand, but just to say that anything that is ePub-centric is totally unhelpful to a large segment of people.

Comment by John Goerzen —
fbreader has a collection browser & device sync'ing

Thanks for the info on Calibre; it seemed overengineered to me and you've just confirmed that. That said, I haven't used it since discovering fbreader.

fbreader has a fine collection browser, although on mobile you have to pay a small amount to get the version of the app which shows cover images (I did this only to support the developer). If you're willing to use Google Drive it also does device synchronization; you upload at https://books.fbreader.org and then can download to any device. It also reads several formats (epub, mobi, fb2, CBR, PDF...), so no need for conversion. My main complaint is that it doesn't reflow text in PDFs, which is annoying when reading on the small screen on my phone, but that feature's on the short-term roadmap.

I know this app is less useful to people who want to use an actual ereader and/or don't want to store their books with Google, but for others it's worth considering.

Comment by mvc —
many comments

Hi everyone! Thanks for the many comments! I'll respond to the last few all together...

toton re okular: thanks! that's what i was looking for, and I confirm it works. I updated the article accordingly

monkey re git-annex: git-annex might provide the faceted search functionality that Calibre provides but, to be honest, my luck with git-annex metadata has been hit and miss. It kind of works, but for large collections, it's slow as it needs to rebuild the worktree every time you "search" something. And the user experience is really not that great: I often get confused between git branching commands and git-annex metadata commands, so much so that I quickly have no idea what's going on anymore...

john re Kindles: honestly, I don't consider Kindles as part of my workflow. I completely boycott Amazon as a company for various reasons aside from the ebook problems, but specifically their attitude regarding contents on their devices has been problematic, to say the least. I understand it was to respond to a copyright litigation, but they did delete Orwell's 1984 and Animal Farm from every Kindle device out there. They are also very aggressive in creating hurdles for us to work with their devices, as you aptly described.

So while they are shiny and enticing, hardware-wise, I don't consider them as part of my use-case model. So yes, I'm digging in my heels and I focus on standard contents: the hardware providers that do not follow that model shouldn't be encouraged with our wallets. I know it's not very helpful to the large number of Amazon users, but then again, I don't feel like going out of my way to help you people either. ;)

(And, generally, people shouldn't feel the need to defend Calibre or apologize for defending it. Again, I have used Calibre for almost a decade (probably around 7 years now, according to the first bug report), and I feel grateful for the services it has given (and still is!) giving me. So I didn't mean to write this as an attack on Calibre, but mostly as an exploration of how parts (or all) of it could be replace, if that's needed for people. It's maybe unfortunate that I started with a rather critical section, but I felt it was important to explain why I was considering this in the first place, And, I have to be honest, I kind of had a chip on my shoulder with Calibre for a while, having dealt with it through the Debian LTS security work and numerous bug reports.)

mvc re fbreader: so I've tried fbreader again and again, and I can never get used to it. It's installed on my phone, as a PDF reader, and I also have it on this laptop. Neither works very well. The phone version has this weird "bookshelf" browser that looks like a an wooden bookshelf, which is not very useful but does looks pretty. Similarly, the user interface on the desktop is ... really confusing to me. There a bunch of small buttons on top without any labels... Kind of hard to use.

The desktop version of fbreader here taks over 30 seconds to start. When I finally managed to find how to tell it where my book collection is, it crashed after a few seconds of walking the tree, with an epic segfault (Debian bug #941886):

oct 06 23:17:13 angela kernel: FBReader[16757] segfault at 8 ip 00007fb8e62800a2 sp 00007ffd84099070 error 4 in libzlcore.so.0.12.10[7fb8e626f000+54000] 
oct 06 23:17:13 angela kernel: Code: 8b 7c 24 30 48 8d 43 30 48 39 c7 74 05 e8 e6 06 ff ff 48 8b 7c 24 10 48 83 c3 10 48 39 df 74 05 e8 d3 06 ff ff 48 8b 44 24 08 <48> 8b 78 08 e8 05 f0 fe ff 48 89 ee 48 89 c7 e8 aa 01 ff ff 48 8b

I was able to workaround the problem and I do have a library browser now, so that's pretty cool. I also like that there's an easy way to add books in there...

It also looks like fbreader is severely out of date in Debian (Debian bug #765039): it has been shipping version 0.12 forever now, while upstream is at 0.99. Which version are you using? Even then, that version is over 3 years old now, and it seems fbreader turned proprietary in 2015...

As for PDF reflows, I have found this generally never works. I have never found PDFs to be reflowable, that's just basically an impossible problem to solve, especially with LaTeX-like, scientific, two-column articles. The best, for this, is to just read the PDF on a bigger screen, and for that those bigger e-readers are just great, albeit expensive.

Comment by anarcat —
Replace vs Fix

This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3? They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870

You don't have to be a Python developer. It would be helpful just having some willing beta-testers provide some feedback.

Either way, thanks for providing a roadmap of comparable software. I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.

  • Jim
Comment by Jim Sorenson —
comment 11

I have only used the latest stable fbreader Android app, which is proprietary but still actively maintained, and for me "just works". When the project went closed source in 2015 a free software fork targeting Android was created, but I've never tried it: https://gitlab.com/axet/android-book-reader

The free app's bookshelf view was a little annoying, but as I said I was happy to give the developer a small sum of money for the "premium" version with a better collection viewer.

I'm not surprised that PDF reflowing would be impossible in the general case for a multicolumn document, but I'm hoping they'll come up with something workable for some of the lengthy books I want to read that were only available in PDF format from the local library. At least I can borrow the physical books if needed!

Comment by mvc —
comment 11

This appears to be an awful lot of effort to migrate from an open-source project. Perhaps that effort could be applied to helping out with the migration to Python3? They have a working Beta now: https://github.com/kovidgoyal/calibre/pull/870

You don't have to be a Python developer. It would be helpful just having some willing beta-testers provide some feedback.

I actually am a Python developer. If Python 3 was the only problem with Calibre, I would totally and enthousiastically go that route. But as I explained in the blog post, there are other problems here.

Also, there's only so much time in the day. I am already involved in another major Python 3 conversion in a program we salvaged from being abandoned by its maintainer (linkchecker) and it's basically taking all of my free time at that level right now. I have my own programs I need to port to Python 3. So, sorry, but I don't have (free or paid, actually) time to offer to the Calibre community right now. But you should know that I did contribute quite a few times in the community (bug reports, security backports and patches). My experience then wasn't as great as I would have liked and I prefer not to get involved anymore.

Either way, thanks for providing a roadmap of comparable software. I personally don't want to switch from Calibre, but seeing the alternatives is always helpful for finding ways to improve.

Thanks! That's the spirit with which I'm writing this. I might end up continuing to use Calibre myself too!

Comment by anarcat —
Calibre replacements

Yeah, I noticed some problems with Calibre as well, in 2013.

https://seegras.discordia.ch/Blog/life-with-calibre/

I've written some software then, mainly to speed up extraction of epub-metatags by a factor of 100(!), but it's grown into a veritable zoo of scripts. You can find them on my site. Mainly:

  • https://github.com/Seegras/epub-meta
  • https://github.com/Seegras/metatags

... might be helpful.

In any case, your posting helped me too, if for not other reason than I know now that atril can read epubs; but hopefully this calibre issue leads to more epub-related software packaged for debian.

lucidor, btw., was nice, but it's ancient. Not worth porting anymore.

BTW: you're managing your books in git-annex? How does that work exactly? I'm interested to read another blog-posting about that ;).

Comment by Peter Keel —
git-annex
Re. git-annex, nothing special. I had some hacks to make it ignore the .db file, because Calibre would be really upset if it can't open (ie. write) to the database. But now with "unlocked mode", it's not really a problem anymore.
Comment by anarcat —
Or an epub to HTML converter plus lynx…

I wrote this small shellscript for myself…

http://www.mirbsd.org/cvs.cgi/contrib/hosted/tg/unepub?rev=HEAD

… which unzips an EPUB file and converts the toc.nxc into an index.htm which I can then use with lynx (the standard text mode webbrowser).

Comment by mirabilos —
Security around epub

Hi Anarcat! One security issue of book readers is that they often follow URLs inside EPUB files (in HTML, CSS, SVG) and execute javascript.

e. g. https://github.com/babluboy/bookworm/issues/283

Comment by federico3 —
Comments on this page are closed.
Created . Edited .