Five interesting facts about Adobe legacy eBook RMSDK
It’s no secret Adobe Reader Mobile Software Development Kit is used by a lot of “eBook companies”. Check this list and you’ll probably get why it is to eBook Reading Systems what IE 6 was to web browsers.
By “legacy RMSDK” I mean “The RMSDK that only supports ePub 2.” Problem is it’s still pretty widespread for various reasons: updating eInk readers looks like a tough job, when all you sell is fiction there is no huge incentive to update, the new one which supports EPUB 3 is rubbish, resellers are tied to the Adobe DRM which you can break in 10 seconds… tops, etc.
So we must deal with dat crap; if we didn’t care, we would provide a shitload of users with a terrible user experience—this very experience the legacy RMSDK provides by default.
While doing some experiments for Blitz, the eBook framework we’ve built, I’ve discovered some interesting facts about the legacy RMSDK.
And oh boy does it feel like it immerges you in an absurd world in which laws of physics don’t apply.
How the fab’ five was tested (!important)
Although screencaps of Adobe Digital Editions are used in this post, the test files have been tested in an awful lot of apps and devices using the legacy RMSDK (ADE, Bluefire, Aldiko, Bookari, eInk Readers, Tolino, DataLogics Reader, etc.), on multiple platforms when possible (Mac, Windows, iOS, Android).
This means all of those facts don’t just apply to Adobe Digital Editions but to the RMSDK itself, consequently impacting all the apps and devices using this “wandering engine”.
Please also note that with the oldest versions of RMSDK (< ADE 1.7.2), any of these 5 will crash the app/device. And this is the reason why eInk readers’ manufacturers, for instance, should update software, even for their oldest models, at all costs. If this isn’t part of your strategy, you’re slowly but surely digging your own grave.
1. It’ll crash if you leave empty amzn media queries in your CSS
Yep, not kidding.
Say you left the following in your CSS.
@media amzn-kf8 {
/* Yeah, don’t need it for once, my CSS is dope, my CSS skills are pure swag! 🙌 */
}Open your ePub in ADE and… it will crash, except if it is an EPUB 3 file in the RMSDK versions which support EPUB 3—FYI, it is using an early version of Readium because who needs the latest version without all the painful bugs?
[insert the gif I’ve spent so much time doing but which Medium rejected because of an unknown error]
On the other hand, you’re now armed with a powerful weapon which, used on a very large scale, has the potential to annihilate the whole RMSDK business—I know how to crash iBooks too but the price is $1,000,000.
[Update] It will also crash if you’re using border: 1ch solid currentColor (1ch is the culprit in there).
2. It supports unicode classes
And it’s not supposed to do that. Per spec. But anyways…
If you are doing the following
.© {
font-size: 0.8125em;
}You’re pretty safe.
3. It doesn’t support emoji classes
And this is interesting since, if you’re crazy, you could use this hack to do progressive enhancement. Indeed, you would be pretty safe anywhere else. It’s as easy as…
.💩 {
font-family: -apple-system, "Comic Sans", sans-serif;
-webkit-initial-letter: 6 1;
initial-letter: 6 1;
color: brown;
}Legacy RMSDK ignores it, EPUB 3 Reading Systems and ePubCheck love it. But don’t use this trick. Thanks!
4. It ignores your whole CSS if it finds a CSS prop or value it doesn’t like
That’s the beauty (cough cough) of the legacy RMSDK: uncertainty.
Let’s imagine you’re one of those fearless heroes using modern CSS. You’re likely to use something like…
blockquote {
margin: 1.5em 0;
border-left: 0.3125em solid red;
padding-left: 5%;
padding-left: calc(5% - 0.3125em);
}Congrats, legacy RMSDK can’t cope with calc() and will just ignore your entire CSS instead of ignoring this one and only declaration!
Problem is the unsupported props/values are not documented so you’d better debug like a maniac.
Shit happens… but it happens way more often in legacy RMSDK.
5. It somehow supports rem
Except it doesn’t.
At this point, you may probably tell yourself “well, if it ignores the whole CSS because of calc(), it would be logical it ignores the whole CSS because of rem.” And you would be wrong, mate.
Don’t forget the legacy RMSDK is an absurd world in which basic laws of physics and logics don’t apply.
As a matter of fact, it treats rem as em.
Holy. Fucking. Shit.
So let’s say you’ve got…
html {
font-size: 62.5%; /* 10px */
}
body {
font-size: 1.6rem; /* 16px */
}
p {
font-size: 1.6rem; /* 16px */
}In legacy RMSDK, what you get is…
html {
font-size: 100%; /* 16px, cos’ obviously, it is overriden */
}
body {
font-size: 1.6em; /* 25.6px */
}
p {
font-size: 1.6em; /* 40.96px */
}And you end up with that shit.
But at least you can change the font size, unlike when declaring font-size in px.
¯\_(ツ)_/¯
Bonus: the only thing legacy RMSDK does well
Let’s end this post on a positive note so that Adobe’s developers don’t consider me a complete asshole.
There’s one thing the legacy RMSDK does really well: page breaks.
In EPUB 3, if you’ve got…
h2 {
page-break-after: avoid;
}Chances are absolutely nobody supports that… but legacy RMSDK does. 👍
Indeed, it enforces this declaration and your <h2> won’t find itself at the bottom of the page like a troll you want to kill every fucking time you encounter him.
This is a call to arms, Webkit, EdgeHTML, Gecko & al. Please implement page breaks and don’t let the crappiest piece of software ever bring shame upon you. If you do, you’ll make the #eprdctn world a better place.
XOXO
