I shipped a couple of things on Flash back in the day but it was staggeringly bad software — random crashes, various heisenbugs where changes in one area would affect unrelated functionality in other modules, etc. — and while it cost something like $800, it was completely unsupported: I filed a number of trivially reproducible bugs with reduced test cases but never heard anything back until the next release came out and they sent automated suggestions that the bug might be fixed so I should buy a full-price license and find out.

There is no way to get access to it. I don't mean the licensing cost is prohibitively expensive for an indie dev although I understand that to be the case as well.

There is no one to talk to. The email listed on their website does not respond to anything. Not even so much as a "Thanks for your interest" or a "We will get back to you".

I messaged a former colleague who worked there to try to see what the process is to get access to rmsdk. He said he tried to find internal docs about it and couldn't find anything.

I tried to find people on linkedin who might be associated with rmsdk and ask them and similarly found nothing.

Meanwhile publishers only distribute most of their titles with one of their known drm vendors ie Apple, Amazon, or Adobe. The other two are entirely closed off.

If this isn't anticompetitive trust behavior, I don't know what is.

The case mentioned where the CSS min() function is rejected is another place where bulk import of the extremely complex CSS spec is just not helpful. Ebook readers aren't evergreen browsers after all.

[1]: https://news.ycombinator.com/item?id=41326179

https://pine64.org/devices/pinenote/

More expensive and less out-of-the-box software, but straight to the point on device ownership/what kind of software you can run, fewer strings attached.

[EDIT]

Great experience blogs on the PineNote

https://shom.dev/posts/20250308_pinenote-day-one/

https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...

TBH i've being using an ePub reader that i occasionally had to edit ePub files so i get rid of the superfluous styling that made it either not work or show things weirdly/wrong and i've heard comments from others that a bunch of files i had no issues with personally were unreadable for them, which makes me think that unless you really and absolutely need any fancy formatting (i.e. math stuff that can't just be made images - and you really tried to!) then you should stick with the most basic HTML imaginable - things that not even IE4 would render (too) wrong.

And in turn, since i doubt this will ever happen, i sometimes ponder making an "epub reconstruct" tool that attempts to reconstruct epubs so that they use the simplest HTML/CSS :-P (ideally configurable for maximum compatibility).

I used a Kindle for ages, always in airplane mode and only sideloading content. Honestly, it was a pretty good setup.[1] But it seemed like it would be harder to setup this way on newer devices, so when mine finally failed, I got a Kobo Clara BW. I was thrilled I could boot it up in "sideloader mode" and not even register it or enable wifi.

I noticed poor typography on my epubs, learned about converting to kepub so I did that (which helped). It was a familiar flow to what I was used to converting to azw3 for the Kindle. My remaining typography gripe with kepubs is that it treats a word+em-dash as a word for inserting space in full justification. Em-dashes generally don't have spaces on either side, this often looks like a space has been inserted only to the right of the em-dash.

I went down the rabbit hole of NickelMenu and other readers including KOReader and Plato, and even tried (and mostly failed) to vibecode my own opds client app. (because KOReader which has one built-in felt overwhelming)

My current sense is the device feels so much more like it is mine. I have much more flexibility to tinker with it. It is not as polished as the Kindle and the Adobe rendering feels stupid, but that's also a sharp edge that only the side-loading community will hit, most of whom use Calibre which can auto convert to kepub for them. Everyone else is buying books from the Kobo store and getting them delivered as kepubs.

So in the end, I'm a big fan of the Kobo devices.

[1]: Except you cannot remove a wifi password if you aren't in range of that wifi signal. I had a rude experience when my two-year-old was fiddling with my Kindle at my in-laws' house and turned on the wifi where there was still a saved credential. An update triggered immediately and I was frustrated for days that everything in the UI changed.

I remembered one particular master student on the verge of tears trying to compile his LaTeX thesis draft, he took the “write and think about formatting later” too literally and was trying to compile it for the first time very close to the deadline.

I used EPublish for my first novel, Means and Motive, just published here, DRM-free: https://www.amazon.com/dp/B0GYCZJVGX

So far I haven't heard of compatibility issues, so I think EPublish has hit the sweet spot of EPUB targeting. I agree, however, that it feels like the old days of targeting IE6 on the web. Old readers still exist out there, so we have to aim for the lowest common denominator.

I have never seen someone explain the adobe software so perfectly. Using any adobe software is exactly this.

Kobo's added features on top of ePUBs are nice, and their renderer is much better than Adobe's standard pipeline.

So, it's a free upgrade with a terrific local library added on top.

Got a refurbished pocketbook in the end and very happy with it, it reads all imaginable file formats and I can just send books to it via email or cable.

Everything else is better with koreader and it’s super easy to install alongside nickel. And it works very well with calibre + the kobo plugin.

According to the author, Kobo uses CSS from 2013. A quick check with an AI says RMSDK supports CSS 2.1 and parts of 3.

So it's not that the renderer is broken, it's that he believed that epubcheck actually checks against devices and the versions of CSS that those devices support.

This is exactly the issue with test tools: the test tool tests to a spec, but the platform is the gold standard. If you don't like it tough shit.

But isn't that kind of the point of epubcheck? It's surely not intended to validate all of CSS, it's intended to validate that an epub will work... and not working on Kobo devices (probably #2 manufacturer of ebook readers?) is a major issue.

The best ebook format I have ever experienced is .txt and just let the software figure out where the text needs to go.

https://pgaskin.net/kepubify/

Surely it would be easier for someone like kobo to just use Koreader, implement their ui changes and demand as plugins or patches, and forget ade

These days I usually get 90% of the way on google docs, then do the final editing on LibreOffice which can add things like tables of contents and cover image, if it opens on Kindle, Kobo and Calibre I consider it job done.

The epub standard doesn't say what version of CSS must be supported. There were no guarantees modern CSS would work so I wouldn't call the renderer broken.

As such, whenever I get my hands on an .epub file, I go to an online converter, convert it to a .pdf file and nuke it from my system. Then the .pdf gets opened in my FoxIt.

Easy to be dismissive, but IP violations can cost a large company hundreds of millions.

IP lawyers are more important to many companies than their software developers.

If you doubt that, check to see who gets paid more...

This is blatantly wrong.

In a perfect world, RMSDK wouldn't exist in the first place and Adobe would have gone bankrupt and become history at least 10 years ago.

I can't tell what the writing or design are like, because the article renders as a blank page on my old iPad.

Also on my 2026 Kindle Paperwhite.

It's futile to be old man yelling at cloud on HN, but I'm still irritated by web pages that are essentially text, yet can't be bothered to actually display anything. A blank page.

Presumably ePub publications are easier to QA than web pages. They must conform to a subset of web standards.

I'm very grateful for this information and it explains why I've avoided epub opting for pdf over epub as my reader software is old.

I'm am very much on the side of supporting backwards compatibility. It reminds me of the times the M$ used to upgrade their doc standards ... where if one hadn't upgraded, well bad luck.

It's getting very tiresome.

It looks like not a whole lot has changed in that space -- the readers are still the gate for what you can do with the format. Who's available to make a CanIUse for epub readers, to shame them into compliance? (only partly /s)