Calibre: Failed to open
Okular: Ugly, cannot modify margin
bookworm: No two-page view, only scrolling-mode, and scrolling-mode cannot get the reading progress
zathura: too simplify resulting in not know how to use
lector: cannot recognize epub......
Buka: cannot open the book. (I don't get the logic flow, create a list first, then import the book, then crash)
Until I found Foliate, it support two-page view w/ progress bar, it support epub will in different language (I test en_US and zh_TW), fast lookup (gtrans, Wiktionary, Wikipedia), good UI, ...etc
Perhaps this says more about Arch than it does Calibre.
Fatal Python error: PyQt5.QtCore: Unable to embed qt.conf
 13321 abort (core dumped) calibre
At that moment, I didn't have time to workaround on it :(
I don't use it to read (I have an e-reader for that purpose), but I'd be lost without Calibre for ebook management.
Sorry for the snarkiness in my previous comment, if you get the chance perhaps you can look into helping with this issue. Contributing to the distributions I use has taught me a lot about the tools I use every day.
It does 2 page view, optionally shows progress, and with the mupdf backend supports epub and pdf and a few more.
Now it doesn't support mobi but calibre can automatically create an epub from the mobi on import.
Calibre is still useful in 17 different ways even if you don't actually use it to read the book.
 config: https://pastebin.com/raw/NwYB0JNf
This is how it looks:
.. come on
I don't mind it, and if it bothers you, you can easily alias it to something else
The package prefix is mandatory, in order for flatpaks not to stomp on each other.
It will do neat things like convert to Kindle & email to the Kindle address with a button press as well so I can give access to my mum and so she can seamlessly read the epub books I have in my library on her Kindle.
It doesn't look great on the Kobo, but I can navigate pretty quickly to download a book, and I hardly ever have to touch calibre itself.
It's pretty easy to get set up running headlessly on a server somwhere.
- reflow on window size change
- allow me to pick any system font to read in
However, Atril, which was originally forked from Evince, does support EPUB rather well.
If it's obvious to anyone else what's wrong here, it's not obvious to me. Isn't one of the advantages of interpreting the code on the target platform supposed to be portability? If so, why is it I so seldom can can get anything written for GJS, or Node, or a Python program not my own, to install and run without a three-hour yak shave?
I'm sure this is a great project, and I mean no disrespect to the author, who did a better job of installation instructions than most — but I'm tired of installation being such a pain. It's almost, but not quite, enough to make a guy run Windows.
One of the bullet points from the Meson website:
> * fun!
So if I understand correctly, this modern build tool created to replace all the extant time-wasting build tools got memorialized in Debian in a half-baked state where it's not compatible with future versions.
Also-- the fact that you had to leave the hardened bank vault of apt through the screen door of pip... to install a thing to build other things to run on your system.
I love it.
> If so, why is it I so seldom can can get anything written for GJS, or Node, or a Python program not my own, to install and run without a three-hour yak shave?
... is the question that explains why Electron exists. Every comment on HN about its size, memory usage, and insecurity doubles as a critique of all the problems you just hit with a Linux system.
Electron: "Memory and disk space is cheap enough, but your time will never be."
There's an open issue here on supporting older systems: https://github.com/johnfactotum/foliate/issues/45
I've using Linux as my primary desktop at work and home for going on 25 years.
If you want to use newer software you should pick a distribution that is geared for that.
Debian stable is for people that DON'T want new software or even to try new software.
You are at odds with your choices.
Either switch to Testing, Unstable or pick an Ubuntu strategy ie Long term or every 6 months.
Of these choices Ubuntu is actually more conservative then Testing or Unstable as it walks forward in a predictable time based manner.
(I don't have enough experience with GJS and WebkitGtk to know if slightly older versions would have been workable here, though I believe that approach to be valid in most cases.)
You are making software reactionary arguments for people doing a lot of work to support you touristing their software from an ancient, long out of date software distribution (which is what people that use Debian Stable want).
If you are going to make bug reports or even comments you really would be better to state you are on Debian Stable from the beginning, it's actually rude to make people think you are on a reasonably supportable distro without warning.
Flatpak is probably your best choice to encourage people to be even able to support your distribution choice going forward. The sandbox also has some attendant benefits that will bear more fruit in the future.
I believe this is precisely what Foliate does. It depends on meson 0.40 (released Apr 2017) and gjs 0.52 (released Mar 2018). Sixteen months old dependencies can hardly be considered bleeding-edge.
Yeah, that's not how Debian stable works.
Nothing was! Debian stable doesn't update packages (not even minor releases or bugfixes). They only backport security fixes or very critical bugfixes.
Debian 9 was freezed on 2017-02-05. You'll have the version of every package from this date, point release don't change that.
My only reason for giving the point release date was to say that it's a supported release. You're reading a lot more into my tiny comment than I ever put into it.
Calling it "supported" in the context of the ability to build arbitrary software is misleading. It's supported by Debian for the particular packages included in Debian's package repositories - nothing less, nothing more.
No, it didn't. Of course, Flatpak let me know that my user account didn't have the ability to configure the remote repositories the Foliate flatpakref specified. I could have searched for the right way to do it, but installing as root seemed to work, and it runs fine as a regular user, too!
But, of course, it doesn't. It doesn't have the ability to open files from most folders. I see by searching that you set sandbox permissions in an application manifest file, but I'm not sure I'm that attached to doing any more of this.
edit: I can also open files from anywhere on my PC. Could it be that the flatpak on Debian Stretch is not correctly configured?
I did finally install Debian testing, and it looks like the flatpak problems are resolved, but I decided not to bother installing foliate because of the nearly 700MB of dependencies it wanted over my rural satellite connection. C'est la vie.
Why complicate things? build-steps are the root of all evil.
Although I'm probably living in a cave and didn't use Linux often on the desktop since years, it is common practice now to write Gtk/Gnome apps in JS? I tought Vala was the cool language for that kind of apps...
I think you’re about ten years behind the trend.
For example bookworm, a GTK eBook viewer.
My PC has plenty of resources, but if I'm going to use a browser to read books, I might as well upload it to Google Play Books and use the browser I already have open for other things. It has the same functionality and my progress and bookmarks are synced across devices.
Granted, epubs are easily converted to HTML, but I shouldn't need an additional few hundreds Mb of RAM to read a 5Mb file.
Thank you so much.
I'm starting to think everyone who can write code should try to contribute what effort they can to an open source project. I'm starting to see how a lot of small individual contributions add up over time. A project still needs a good maintainer and vision though, and that's a lot of work for someone.
Also the app itself looks nice and native, good job.
If you want to compile a language you're going to need a compiler and a linker. Do you know how much water it takes to compile a single executable? Water that's better used irrigating a field which could support hundreds of well-written python and bash scripts.
It's all about tradeoffs and I don't think this one is too bad. I'm glad it isn't a pure electron app.
Now we just need decent open hardware for Linux tablets! I'd love to use this program to read books on one of those mythical open source tablets that can run KDE Plasma.
However, you easily can install alternative readers on Kobo ereaders, see here for a list of some hacks:
gpg: skipped "John Factotum <firstname.lastname@example.org>": No secret key
gpg: dpkg-sign.LHxm7FS6/com.github.johnfactotum.foliate_1.4.0.dsc: clear-sign failed: No secret key
dpkg-buildpackage: error: failed to sign .dsc file
edit: build does indeed work and I could use the viewer, building a Debian package fails though.
I am using Freda in Windows to read ebooks.
I was worried about what to use in Linux. The Calibre viewer simply doesn't have the same quality as Freda.
Foliate is great, and I no longer worry about this. Thanks for the heads up.
I actually disagree with you, the UI seems elegant and very usable on desktop. Maybe smallish window size on screenshots give impression that it's more suitable for tablet?
The following are runtime requirements:
gjs (>= 1.52)
Otherwise for long form reading sections I switch back to my Kindle, tablet, or paper book.
The other times I read on my computer are shorter academic papers, reference, and sampling the first chapter of books before switching them to my Kindle or tablet.