I wouldn’t describe reMarkable as a fairly open platform. The one thing they got right was granting SSH root access as a way of complying with GPL and similar licenses, but that’s honestly the extent of its openness from their side, and they’ve rebuffed any appeals from the community that supported them so strongly early on to be in any way more open. Their software is all closed source, and designed in a self-contained way that is fairly robustly non-extensible. Their on-device rendering is superb, but their off-device rendering (used in their desktop software, for example) is mediocre for most writing and outright bad for anything resembling art. (This was the case last time I tried, over a year ago, and I get the impression that it’s still the case—they do something like turning their variable-width strokes into filled paths, then unioning them (to flatten self-intersection) and doing aggressive path simplification. I’m perplexed that they do it this way since it produces an obviously bad rendering on self-intersecting paths, which occur a lot in writing: path simplification needs to be done before unioning, not after.)
Sure, quite a few other people have written software for it or peripheral to it, but it’s all based on reverse engineering, since you’ve got things like xochitl (the UI software that runs on the tablet) being written in Qt with QML so that you can get a certain degree of binary patching (see ddvk-hacks, which customises the UI a fair bit), and their file formats are all sufficiently simple where it matters (some JSON, some plain text, and the stroke data being a painfully unoptimised binary-packed data scheme) that people can approximate most of it pretty well. But I’ve been feeling a growing sense of dissatisfaction in the community on the openness side of things. Many people chose to go with reMarkable because of this ostensible openness and the idea that things would improve, but at least some of it is a mirage, and attempts at extending on-device functionality are decidedly for power-users only who are willing to tolerate various inconveniences.
RCU is… eh. Tolerable. A good bit of work, but weaker than something first-party, mostly because of how it’s built on reverse-engineering and fitting around the whims of the reMarkable team, and how their software is architected. Its syncing is mildly fragile, and I’ve steadily become convinced that its entire approach of doing per-document tarballs containing the files pertaining to that document, rather than just mirroring the device’s ~/.local/share/remarkable/xochitl (which is flat) was misguided, a mistake as a primary approach (use something like that for interchange, sure, but for the typical task of syncing it’s very not good). Its rendering is the best I’ve found among open-source renderers, but it’s still very inaccurate for anything even vaguely arty. I’ve written my own SVG rendering pipeline (which currently means no textures or variable opacities, but only variable stroke widths—and on the point of variable stroke widths I’ve done better than any before me by a considerable margin) that I haven’t yet released, but thinking things through I’ve decided I’m actually not interested in continuing to work in and around a closed tool, so I don’t think I’ll bother going on to a more pixel-perfect bitmap renderer as I had originally planned; I’m more interested in the potential of starting from scratch in a proper open software ecosystem where you can actually add useful functionality to the software, rather than just eating the crumbs that drop from the master’s table. In the mean time, `rsync --archive --verbose --compress --delete $REMARKABLE_HOST:.local/share/remarkable/xochitl/ ~/reMarkable/data/` is excellent for sync.
I look forward to the PineNote getting further. A little way down the line, I’ll be seriously considering getting one and creating good long-form writing and drawing software optimised for it.
Sure, quite a few other people have written software for it or peripheral to it, but it’s all based on reverse engineering, since you’ve got things like xochitl (the UI software that runs on the tablet) being written in Qt with QML so that you can get a certain degree of binary patching (see ddvk-hacks, which customises the UI a fair bit), and their file formats are all sufficiently simple where it matters (some JSON, some plain text, and the stroke data being a painfully unoptimised binary-packed data scheme) that people can approximate most of it pretty well. But I’ve been feeling a growing sense of dissatisfaction in the community on the openness side of things. Many people chose to go with reMarkable because of this ostensible openness and the idea that things would improve, but at least some of it is a mirage, and attempts at extending on-device functionality are decidedly for power-users only who are willing to tolerate various inconveniences.
RCU is… eh. Tolerable. A good bit of work, but weaker than something first-party, mostly because of how it’s built on reverse-engineering and fitting around the whims of the reMarkable team, and how their software is architected. Its syncing is mildly fragile, and I’ve steadily become convinced that its entire approach of doing per-document tarballs containing the files pertaining to that document, rather than just mirroring the device’s ~/.local/share/remarkable/xochitl (which is flat) was misguided, a mistake as a primary approach (use something like that for interchange, sure, but for the typical task of syncing it’s very not good). Its rendering is the best I’ve found among open-source renderers, but it’s still very inaccurate for anything even vaguely arty. I’ve written my own SVG rendering pipeline (which currently means no textures or variable opacities, but only variable stroke widths—and on the point of variable stroke widths I’ve done better than any before me by a considerable margin) that I haven’t yet released, but thinking things through I’ve decided I’m actually not interested in continuing to work in and around a closed tool, so I don’t think I’ll bother going on to a more pixel-perfect bitmap renderer as I had originally planned; I’m more interested in the potential of starting from scratch in a proper open software ecosystem where you can actually add useful functionality to the software, rather than just eating the crumbs that drop from the master’s table. In the mean time, `rsync --archive --verbose --compress --delete $REMARKABLE_HOST:.local/share/remarkable/xochitl/ ~/reMarkable/data/` is excellent for sync.
I look forward to the PineNote getting further. A little way down the line, I’ll be seriously considering getting one and creating good long-form writing and drawing software optimised for it.