Dropbox (and Kobo) are now supported by url2epub
Over this past Black Friday shopping season, I purchased yet another e-ink reader: Kobo Sage.
I wrote before about my frustration with reMarkable Cloud API and switched from reMarkable 2 to my wife’s old Kindle Oasis, but there are still things with Kindle Oasis that annoy me, so combining the shopping season discounts and my employer’s benefits, and also Kobo operates a Taiwan ebook store that I can buy Traditional Chinese books directly, so I decided to give Kobo a try.
Initially there’s another thing that attracts me to the Kobo ecosystem: that they have built-in integration with Pocket, so the hope was that I won’t even need my own url2epub app to read internet articles on it.
But after trying to use Pocket on it for a while (including two trips that I had some long times on a plane), my conclusion is that url2epub is just much better than Pocket to generate articles out of URLs to read on an e-ink reader, for the following reasons:
- Pocket struggles to get some of the images from the articles, like The Verge’s (If any Mozilla engineer is reading this: I already described how I resolve that problem in this previous blog post, my code is also licensed under BSD-3-Clause, so please implement it in Pocket. It’s not that hard).
- Pocket also struggles to get some paywall’d articles completely (e.g. Washington Post), that in Pocket app it opens the original url, while on Kobo those articles won’t be able to be synced at all.
Besides Pocket, Kobo also has Google Drive and Dropbox integrations (according to some internet discussion those actually varies device by device, e.g. not all Kobo devices have those integrations, but there also third-party ways to add those integrations to all Kobo devices). I usually use Google Drive, but Kobo’s official Google Drive integration requires permission to access my whole Google Drive, and there’s no way I’m giving any third party app that permission, so I opt’d for Dropbox integration instead (as a free Dropbox account should be big enough to hold my generated epub files anyways).
In url2epub Telegram bot, you can just use /start dropbox to start the integration, which will give you a Dropbox OAuth URL. After granting permissions, it will give you a code in the end, so you come back with /start dropbox <code> to finish the authentication. After that, you can use /dir command to choose which directory to send those epub files to. Kobo’s Dropbox integration is an app integration that they only have access to files under /App/Rakuten Kobo/, so in order to use it with a Kobo e-ink reader you need to pick a directory under that (I personally use /App/Rakuten Kobo/Incoming/ for it).
After implementing that one thing I noticed is that for some reason my Kobo Sage does not like the epub files generated by url2epub, that the file will just show a blank screen. I tried to use some online epub validator to see what are the problems with the epub files I generated, and fixed some minor issues, but that didn’t make Kobo happy. One thing I noticed is that the validators say my epub’s main html file lacks the XML namespace on the html node, e.g. the spec expects something like this:
<html xmlns="http://www.w3.org/1999/xhtml" ...>
...
</html>
But the epubs I generated do not have that xmlns tag.
I use go’s HTML tokenizer and parser library to strip down readable html and render it in epub. It does have a Namespace field in Node type to set the namespace, but setting it to "http://www.w3.org/1999/xhtml" does not cause it to be rendered (probably because that’s the default and always rendering it will be too noisy?). After some testing, I ended up adding an xmlns attribute explicitly to the html node, which finally made it to render it in the final file, and Kobo is finally able to read those epub files.
Here is a comparison between Kobo showing the epub from url2epub from this article:
versus:
From which you can clearly see the importance of the (lack of) image right above the image caption (“The trajectories of the various fragments. (ATSB)”).
So if you also have a Kobo e-ink reader and like to read long internet articles on it, you can give it a try. There are probably other e-ink reader platforms with Dropbox integrations as well, for example, reMarkable itself also has a Dropbox integration, so this can be used beyond Kobo e-ink readers.
Please note that at the time of writing, my Dropbox app was not approved as production yet, so it has a limit that it can only auth 50 users. From their documentation it seems to me that they would also start to review my production application once my app actually hits (or maybe nears?) 50 users. So if it actually gets traction and hit 50 users before it gets approved by Dropbox, new users won’t be able to auth, I guess (If any Dropbox engineer is reading this, please expedite the review of my app 🙇). UPDATE: It’s now approved by Dropbox on 2023-12-28!