Free Ink · An open ecosystem for e-readers
54 points by Yogthos
54 points by Yogthos
Interesting, but man, is that targeted hardware lackluster. 512KB RAM without any PSRAM? EPUBs are modern HTML (but parsed with an XML parser) and can contain pretty complicated CSS.
I can see why this is the minimum target, as it originates as a project made for devices with ESP32-C3, but the fact that the open hardware doesn't suggest something with PSRAM, and the firmware doesn't use any anyways? Ouch.
I have a Xteink X4, which is one of the targeted devices, and I haven't had any trouble reading any of my epubs with it yet.
Can you try this one? In particular, do the code listings look right (numbers on the left)? Calibre had a bug in its CSS rendering that made each line of a code listing indent further than the previous one. For comparison, the web version, which should have the same presentation and the PDF version (which has slightly simplified presentation in a few places and is closer to the print edition).
The Xteink X4 has a screen that's about two inches wide. I think if you try to read a code listing on it you are going to have a bad time, even if it managed to render it completely properly.
I absolutely love this device but it is 100% for reading natlang text.
No, it has a completely different formatting error. No line numbers, and also no line endings, in code listings. Lines are joined with some whitespace between the end of one and the beginning of another. It does open it though, and pretty much everything is present and readable, even if not correctly formatted.
I'll also say that the whole thing doesn't render very well in Foliate (Gnome desktop ebook reader) -- it has extremely narrow columns. Code listings suffer the same narrow column problem, but do have line numbers, correctly aligned. In KOReader (in this case on a Kobo Aura), the code listings look okay, but they do not have any line numbers.
I wish the ePub spec would define a subset of CSS that every reader supported. For reference, this ePub passes the validator with no errors, so incorrect rendering is a bug in the reader, but every reader implements a different subset of the allowed CSS spec (except the ones that just wrap a web view). My favourite stupidness is Apple’s Books app, where they do the pagination after rendering and so, depending on your text size and page size, will put page breaks in the middle of figures (and, yes, they are wrapped in the no-page-break-here CSS attributes, but Apple Books ignores that, though it does support the attribute for a recommended page break).
Posting this here in case anyone else finds it useful. I've often wanted to be able to read on my phone on the go, but also read on an e-ink device when one is available (I have a Kobo Libra 2 and a Remarkable Paper Pure). I also want the reading experience optimized for the device I'm reading on (no extra animations on e-ink, native app on iOS).
The solution I've come to is KOReader on the e-ink devices and BookFusion on iOS/web. BookFusion now has KOReader sync built in, so I can bidirectionally sync my progress. It's not perfect, but it gets the job done.
What's the story on DRM? I couldn't find anything about it on the site, but if this device can only read DRM-free titles, then that's really limiting. To me DRM is the main blocker to an open ereader ecosystem, and I don't know that open hardware will change that.
Most ereader software will only read DRM-free files, regardless of platform. Generally you can have a quality ereader experience, or read DRM files, choose one.
KOReader sync
I wish someone would make the functionality of KOReader sync but ONLY sync. KOReader takes over the whole reading experience and uses a lot more battery.