Adobe has always been like this, too. They squandered an enormous marketshare with Flash because the alternative would've been spending a couple million on QA and they managed to unite all of the browser manufacturers in agreement that the web was better off without such an unreliable partner.
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.
The best feature of flash was that it was so easy to disable. Because 99% of the use was annoying ads that pinned your cpu at 100%.
And that was Jobs argument, that it was too resource intensive. Predictably though, now that annoying crap moved to "newer" tech (javascript) and now we can't disable it as easily or without as little consequence. Just as resource intensive though...
I never bought the benevolent technical angle for not supporting flash. I'm pretty sure Apple strategists knew the value of the gate-kept platform, the app-store revenue stream.
The pivotal point was that flash would break this stronghold by allowing rich applications that are reasonably self-publishable. (Excuse me while I go rinse that sentence out of my mouth)
I think the Appstore was planned all along, just did not fit in the first release, so they adapted the launching narrative to: "the browser is enough for all 3rd party software".
Vocally public yes… but they wanted to see what the diy scene created, how the power users were using the device and letting them develop the ideas and implement… they would open up and co-opt… boss tools is your drag down for all your settings case in point.
This has been openly admitted to in interviews after the fact.
They 100% did not let the power users and DIY scene exist. It only existed by exploiting OS security vulnerabilities. Every new iOS release required finding a new way to crack it. That's why a lot of people chose Android.
Apple didn't even have an AppStore in mind until people started hacking apps onto it.
Remember back in 2007 when Apple first told developers that to develop for the iPhone, they’d need to build WebApps for Safari? Well, that really was the plan. At the time, Jobs said:
The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services. They can make a call, they can send an email, they can look up a location on Google Maps.
And guess what? There’s no SDK that you need! You’ve got everything you need if you know how to write apps using the most modern web standards to write amazing apps for the iPhone today. So developers, we think we’ve got a very sweet story for you. You can begin building your iPhone apps today.
The App Store came later and apparently as a reaction to jailbreakers and developer backlash.
According to the biography, Jobs’ longstanding animus toward Adobe helped form his vision for Apple’s tightly controlled mobile environment.
In 1999, he was flatly denied when he asked Adobe to create a version of its popular Adobe Premiere digital-graphics software for the Mac. Adobe also wouldn’t rewrite Photoshop for the Mac’s operating system, even though Macs were popular with designers.
“My primary insight when we were screwed by Adobe in 1999 was that we shouldn’t get into any business where we didn’t control both the hardware and the software, otherwise we’d get our head handed to us,” Jobs said, according to Isaacson.
The two companies go back together even further. Apple invested in Adobe in 1985 and they worked together early on. But Jobs, who in Isaacson’s book comes off sometimes as vindictive and brusque as he was innovative and inspirational, told Isaacson that Adobe went downhill after founder John Warnock retired.
“The soul of Adobe disappeared when Warnock left,” he said. “He was the inventor, the person I related to. It’s been a bunch of suits since then, and the company has turned to crap.
I remember seeing stories about Adobe not being able to, or not wanting to, write a good energy efficient flash renderer for the iPhone, thus being another reason not to support it for Jobs (Adobe being of the mind that "Flash is so big, they'll have to support it" and Jobs proving otherwise)
They also either could not or would not write efficient Flash clients on Mac OS or Linux, while the Windows version was fine.
I bounced around a lot between the three OSes at that time, and Flash was bad enough on the other two that I would almost automatically reach for Windows when I had to use it.
Flash had many issues for sure, first and foremost security. But I can’t help but feel sad of what was lost since then. The Flash era produced some really unique experiences on the web.
The JimCarrey.com website was cool. That's about the only flash thing I came across that was though. Now gone as a site but recorded on video https://youtu.be/B1XZixLBurQ I'm not sure you can do those things in javascript to this day?
Lot of it was bad, sure, but there was so much games and animation done by literal kids back then, because of how easy it was to create something with the tooling. Nothing even come close today, unfortunately.
Flash is still unsurpassed as the easiest publishing medium.
JavaScript build system layer cake and "web standards" are a million times harder than just drawing some stuff, maybe writing a simple function, then building a static file that can be embedded anywhere and even downloaded. You have to spend so much time setting up any flash alternative, and the "standards" are worse.
I hate Steve Jobs for killing Flash and Adobe for being such awful stewards of one of the most amazing web technologies.
Kids growing up today have no idea how magical Flash was. It was like Roblox or Minecraft for web.
Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power. And none of its ease.
Magical? Those are some rose tinted glasses. Having to install a binary blob from a free-software hostile vendor that wanted a monopoly to load a website was always ridiculous ask. Flash was a constant embarassment of RCEs vulns and virtually non-existent Linux support.
I remember the time of browser plug-ins (not “extensions”). Everyone happily installed Flash, and the Crescendo midi plugin, and multiple other in-retrospect-ill-advised plugins to enable fun stuff to work in their browser.
The “everyone hates Flash” stuff came later. It served a purpose for quite a while and people loved it. Newgrounds was a place of magic.
I mean, flash was always a pain in the ass, even when you got it working. The animations and games were great and I'm a big fan of stuff that tries to make it easy to publish programs like that, but I was still a teenager when apple announced they weren't supporting it and I was genuinely happy because I was so annoyed using it even on a windows pc.
> Having to install a binary blob from a free-software hostile vendor that wanted a monopoly to load a website was always ridiculous ask.
The entire browser ecosystem started out closed source. Even JavaScript was written to interact with closed source Java Applets.
> Flash was a constant embarassment of RCEs vulns
Browsers still are the goto target for contests like Pwn2own. It is almost like inviting the entire world to run untrusted code on your computer is not a great idea, no matter how many security buzzwords browser makers like to throw arround.
> The entire browser ecosystem started out closed source.
That is completely, 100%, untrue and not remotely historically accurate. WorldWideWeb (the first web browser) was public domain. Lynx came out in 1992. Mozilla was open sourced in 1998. There was never a time when the "entire" browser ecosystem was closed source. It certainly didn't start that way.
> Even JavaScript was written to interact with closed source Java Applets.
> Netscape decided to add a programming language to Navigator. They pursued two routes to achieve this: collaborating with Sun Microsystems to embed the Java language, while also hiring Brendan Eich to embed the Scheme language.
> The goal was a "language for the masses", "to help nonprogrammers create dynamic, interactive Web sites". Netscape management soon decided that the best option was for Eich to devise a new language, with syntax similar to Java and less like Scheme or other extant scripting languages.
> [...]
> The choice of the JavaScript name has caused confusion, implying that it is directly related to Java. At the time, the dot-com boom had begun and Java was a popular new language, so Eich considered the JavaScript name a marketing ploy by Netscape.
Some people might have used it for the purpose you claim, but that's not why it was invinted.
> Netscape decided to add a programming language to Navigator. They pursued two routes to achieve this:
And the reason for that two language approach is given in the linked source:
> We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers—the Web page designers—would assemble components and automate their interactions using [a scripting language].
Earlier sources clearly state that Java was intended as the primary language and JavaScript merely acting as glue.
Yeah but we were kids, we didn't give a shit about any of that. Kind of still don't give a shit about any of it tbh. There's security holes in everything anyway.
The overwhelming majority of computer users simply DO NOT CARE about things like "install a binary blob" or "free-software hostile vendor" or "non-existent Linux support". They installed the plugin and got a way better experience.
> Flash was a constant embarassment of RCEs vulns
I wonder if anyone has done an analysis of Flash versus Javascript (or other browser technology) vulns over their respective lifespans.
If Flash hadn’t sucked harder than a neutron star, that would be an argument to have. People install lots of proprietary plugins today. Flash would’ve been just one more on that list.
But it did suck, and badly. It crashed the browser all the freaking time, often hard enough to crash the whole OS. (“But the OS shouldn’t let that happen!” True, although even with that said, it was in the short list of common apps capable of crashing that badly. It was almost a talent.)
Flash was horrid. While idea was fine, the implementation was terrible. No mobile OS could have run it solidly and without sucking batteries like no tomorrow. Flash in the right hands could have been nice. We’ll never know because that never happened.
> No mobile OS could have run it solidly and without sucking batteries like no tomorrow.
By the time mobile could run Flash, it was too late. Between Apple & Adobe, it had no shot of making the transition. But before that, Flash was pretty amazing.
It was never amazing. It was adequate to give creative people a way to work around its many shortcomings and make something cool anyway. The tech and the implementation was awful, and all credit goes to people who still managed to shine through it.
For all the many reasons people might dislike Apple, they were 100% in the right on this topic. Flash needed to die. It got everyone to collectively push the web standard technologies ahead into something way, way better.
> The tech and the implementation was awful, and all credit goes to people who still managed to shine through it.
Sorry, that's simply not true. The tech was ahead of its time. The implementation was intuitive. Only developers and Steve Jobs hated it, because Flash made it way too easy for anyone to make something fun.
And yet, there was no html5 newgrounds. The magic of flash was that it gave a space where a music person, an art person, and a programmer could bang something out. The barrier to entry was comically low, which allowed an absolute explosion of content.
Sometimes good products happen despite bad technical foundations.
> Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power.
Is this a troll? What could an application do with Flash in 2005 that we can't do with a modern web application today (excluding the obvious answer of runtime vulnerabilities that allowed apps to escape the sandbox)?
> What could an application do with Flash in 2005 that we can't do with a modern web application today
Show me the JavaScript framework (or tool that exports JS) that you can give it to a middle schooler and have them make a cartoon with audio and moving images that they can draw themselves, while responding to user input. Have the exported artifact be consistent across all major operating systems and browsers.
Flash had its problems but as a user, it looked sharper and smoother than even current websites. And its editor gave non-tech users ability to create amazing animations, interfaces, and even games.
wasn't some of that smoothness because it ran at a 100hz tick without any way of adapting it (and still running existing code)? That was the complaint I kept hearing from people attempting to make flash on phones viable (this led to ludicrous battery consumption)
This was intended for a slow 2004-era computer with a 4x3 (probably 1024x768) display, where it worked very well.
But it's not 2004 anymore; things are much faster and screens have gotten a lot bigger. Here in 2026, Salad Fingers renders out fine at higher resolutions, and at different aspect ratios. It works great on my desktop at 1080p, without stretching [and with some probably-unintentional extra content on the sides]. It even works on my pocket supercomputer's 3200x1440 20:9 display.
Vectors are fun, and they scale as technology improves. The lines remain smooth and defined. And with Flash, that's a built-in: An unaltered 22-year-old digital animation still looks crisp.
For contrast, if Salad Fingers had been published on YouTube way back around that time, it would have been in chonky fixed-pixel 320x240. Maybe that would be as good as it would ever get unless it were rendered and uploaded at higher resolutions later.
what’s he is referring is the editor and the easy way of drawing things, still agree we can do things today but a easy to draw editor like that is missing. I was a fan of flash and fireworks.
The editor was a scripted timeline, similar to a video or animation timeline. It was fantastic for creatives, but counterintuitive for programmers, so most devs hated it.
This went away not only because flash died, but also as the internet commercialized.
I mean, consider this: McDonald’s used to be fun and colorful. Now every McDonald’s is boring and gray. And, wait, every store is boring and gray! And flash had nothing to do with that.
You'll get hammered for this on HN, but the web was magical and weird with Flash around, and now it feels quite vanilla and boring. I long for the days of weird experimental art and goofy animations and bonkers UIs.
It was a fun and experimental time for sure. Way more stuff was weird in a good way. Standards hadn’t settled. All kinds of fun stuff was created in Flash that could not have been built with the standardized web tech of the day. I don’t really miss Flash but I do miss the early internet sometimes and Flash was part of that. (Remember when it was FutureSplash?)
I would be remiss if I didn’t post the most early-Internet-type thing I’ve encountered in a long time. Dungeon Soup.
I would rather say, that now the web feels like being handed turds at every turn, and needing to wear a hazmat suit, if one wants to stay clean. Not what I would call boring. More like infuriating.
Yeah but the execution still mattered. I'm a Flash / Shockwave fan as well but there's no point pretending that package was sufficient for the job it was pitched to do. Macromedia seemed to be on a really good track with Shockwave and Flash, but either didn't set up the technology for internet success, or really just sold out the goods with the Adobe acquisition.
In any case, take heart though. If we did it once, we can do it again.
What I never understand is why we never got a Flash-level authoring tool that exported to modern JavaScript/Canvas. Ruffle shows it can be done.
Adobe could have retuned Animate to do it, but instead let it languish as a niche animation tool for some animation studios to use before trying to kill it.
Those downvoting you have no idea of what you are talking about. Flash was what truly brought multimedia to the internet. You could make complex vector animations so easily in it, and it would only take a few minutes to load on a dialup or ISDN because of its small size (10's or 100's of KB). At one point, it used to power the whole of Youtube (and many other video sites). "Web applications" in this era actually meant something built with Flash. And it did all this on ancient hardware. Flash used to run on 90+ % of internet connected PCs at one point if I remember right. And because of that, you could count on Flash player more than the browsers they ran in. Adobe 100% screwed it up.
That said, I wonder how easy it is to publish on apple? I think of xcode in sort of the same way sj complaining about adobe being cross-platform and slow.
The problem is that, while there's no theoretical barrier to an authoring tool with a Director-like user experience that exports to Wasm, no one has actually written one, and it's not a small amount of work.
(I agree that we're better off without Flash, but this particular problem is real and unsolved.)
Ruffle is not complete or comprehensive. In my test of a dozen swf ruffle could successfully display about half. Compare to the actual flash plugin Shockwave Flash 11.2 r202 (11.2.202.643) in my retro machine browser which displayed them all perfectly.
this is unfortunately, the most revisionist take I can imagine. I don’t mean this in a personal way, mind you but while it may have been magical to publish interactive websites, using flash, that magic is utterly outweighed by the mundane vulnerabilities that flash was riddled with.
It’s safe to say we all miss sites like Homestar runner, and I had a co- worker who generated many meme – worthy flash presentations of his coworkers, which were hysterical. however, flash generated security vulnerabilities on the daily, and unfortunately, these vulnerabilities were very conveniently cross platform. These vulnerabilities, which Adobe couldn’t, or wouldn’t, resolve resulted in many many lost hours fixing virus – and Trojan horse – infested PCs, Macs, and cell phones. Adobe never managed to sandbox flash at all.
I miss a lot of old flash content, and I’m sure many people miss the ease with which you could create interactive content for websites. The fault here lies squarely on Adobe, who wouldn’t fix the situation.
Compared to the best that someone can vibe code? Not to show my age, but we were kids when flash came out. That copy of macro media? I don't know about you. We spent hours and hours and hours with that spend hours and hours and hours with vibecoding and tell me that you really can't accomplish similar shit. Then you just to deploy it you and I might be to smart to just paste your Vercel API key in ChatGPT, but pretend you're 16 right now.
I can tell you how much tsc sucks off the top of my head but what I can't do is tell you to hit ctrl+enter in Claude desktop to play movie.
What kids know today is how magical Claude desktop and ChatGPT are. The deploy story is trivial. just give the AI the key. We can judge someone for being dumb enough to do that, but unless you're selling consulting services, it's not nice to laugh. if you are selling consulting services then let's talk sales channels lol
> "Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power. And none of its ease."
Somewhat mirrors my experience with all those rubbish non-PDF formats for digital document publishing, e. g. ePub: Often terminally ugly and utterly useless on top of it (not properly citeable, et cetera).
As someone who has spent a good deal of time trying to build ereader software, eventually I decided to try to deal with the devil and build on top of RMSDK.
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 last time I looked into this, readium lcp drm wasn't something US publishers were comfortable distributing their titles with, although it seems like this may be changing, which is good insofar as readium is at least open source and free to build with.
Sure thing. I've actually been working on the spoiler-free resource angle as well. I can book a call to talk. Distribution is the killer problem here though.
Yay! Registrations to https://merrilin.ai are open and you can enjoy a free account for as long as I can afford to give it (I have no funding lol). The android app is ready for closed testing too, if you have an Android device, mail me at mail [at] stonecharioteer.com and I'll add you to the beta testing. ios is still a pain.
Why don't you do sign in with openrouter oauth, then users can create an account and assign a key to your app, with spending limits. It's trivial, plus if you get a decent amount of users your app will appear on the leader board and that's free marketing for your project.
That's a good point, but our harness right now is very fine tuned towards kimi2.6, it's something we want to improve but it's just 2 broke dudes working on it right now.
AIUI, Kobo devices have a more advanced rendering engine if you name the file with .kepub.epub. (I think it's based on ePub 3?) Not sure if it would fix the problem here. But I personally run ePubs through kepubify (https://pgaskin.net/kepubify/try/) before transferring them to my Kobo.
I love my Kobo (clara colour) and really, if they just removed the Adobe reader, it'd be perfect. And yes, I've tried KOreader, but never switched to it because I like my Overdrive library books and Kobo Store.
Unfortunately, epub and epubcheck isn't the great uncontroversial resource the author makes it out to be. When W3C, Inc. took over maintenance of the EPub spec around when 3.1 was current, they just referenced WHATWG HTML and other ever-expanding browser specs ([1]). Being "living standards", these have no versioning or QA. As a consequence of being based on a version of HTML that redefined headers and sectioning, Epub 3.2 just made existing epubs non-conforming. Which is why Calibre and other tool still recommend 3.1 or better yet 2.
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.
Yes, it is widely known in the epub space that targeting 3.1 or 2 is the more sane option.
With EPUB compatibility issues CSS should always be suspect number 1. Using "modern" CSS features and complaining about missing flex boxz grid, etc is a web developer's mindset.
Just because EPUB shares some of the stack with the web doesn't mean they perfectly overlap (or even should).
Hardly any e-ink embedded e-reader devices use a browser for rendering, they all use purpose built HTML/CSS parsing and rendering toolchains, are baked into firmware and updated once in a blue moon. (If you're interested look at koreader's crengine or Crosspoint reader which runs on an ESP32!)
The blog post reeks of overly confident AI prose. But don't be fooled.
Came here to say exactly that: CSS was designed to be friendly and just ignore any line it doesn’t understand. It’s the whole point of browsers and progressive improvements.
Are we blaming the spec and the author of the post for trying to conform to the checks, instead of blaming Adobe or Kobo for using 16-year old technology that ISN’T spec-compliant? -.-
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.
Have you tried the PineNote yourself? It $400 and says that it's "aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux." The community provided firmware they link for it hasn't been updated in over a year.
The Kobos don't limit what you can do with them either, you can sideload alternative e-reader software like KOReader that improves on the built-in reader functionality.
I have a PineNote but also (had a Remarkable 1 a while ago) a Remarkable2 and RM Pro. I also gifted a PocketBook Verse Pro and installed Koreader on it.
Basically if you want a "product" to use right now and still want to tinker, RM gives you ssh access to a system you can tinker with. RM2 has the best community support for now though.
PineNote works... but yes you will have to be ready to tinker. It's heavy and think but powerful, all the way to having a browser, audio, microSD, etc.
Meanwhile the PocketBook Verse Pro just works, no tinkering, but also tiny and not get for sketches IMHO.
Exactly, if you don't enjoy sketching concepts, think via diagrams or need to write in order to think then a PockerBook is good enough.
If, like me, you clarify your thoughts by physically writing (not typing) or sketching, then the ability to do so without distraction, moving a piece of text of the page, changing the position of a box in a complex diagram... then it's definitely worth the price IMHO.
> 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.
This note was in the original comment, did you read it? The fact that it is $400 (more expensive) and has less out of the box software is literally mentioned to alert people to that.
> The Kobos don't limit what you can do with them either, you can sideload alternative e-reader software like KOReader that improves on the built-in reader functionality.
This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development:
The point is to buy hardware that is built for you to freely modify and fully own, from the start.
My post was to make sure everyone knew the PineNote was an option, because I certainly did not know it until someone on HN made me aware.
Could you maybe make your point more concrete? Are you attempting to completely dissuade people from using the PineNote because it may not be easy to side load apps to it on hacker news?. Obviously different people have different propensities to do hacking, and some may not be able to afford the PineNote due to how expensive it is, but it's not clear what the goal of your comment was.
If your goal was "invest in Kobo instead of PineNote", I disagree with that. I'm not interested in investing (whether money or time) in an ecosystem that is just going to rug pull me eventually, over nickels and dimes.
BTW for those who agree, another great option is XTeink -- very hackable, and I've bought one myself:
Thanks for the link on mobileread. I was not aware of current development in direction of secure boot / chain of trust.
Not OP, but when I was looking for an e-reader, I looked up the Pinenote. I could not find easily a lot of information on its software state. I could find a lot on Kobo hacking. I notably found https://anarc.at/hardware/tablet/kobo-clara-hd/ and this motives me to get a second hand Clara HD for less than 100$. It was way cheaper than starting with 400$ and unknown software state.
I hadn't heard of the Pinenote before looking at your comment, so I looked at the site and saw some things that made it seem unfit for purpose as an ereader. I made my comment because I was interested in hearing your impressions if you were using it as a daily driver.
> The point is to buy hardware that is built for you to freely modify and fully own, from the start.
Personally I view stuff like this as a nice-to-have, not a must-have. If it means I can't have an interface where I can buy books and then download them to my ereader, or I can't have an iphone app where I can read books and have my progress synced between my ereader and my phone, or it's unstable, or the battery life isn't good, then I would rather go with the Kobo. I understand that different people have different priorities, but those are mine. Stuff like this is why I'm interested in hearing more detailed information about what exactly the tradeoffs are for going with something like the Pinenote.
> This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development:
I think you can still sideload KOReader on them, but that's a shame that they're making it harder to replace the stock OS entirely. I hadn't heard about that prior to now so thanks for bringing that up. I only have a Sage I bought a few years ago.
> I hadn't heard of the Pinenote before looking at your comment, so I looked at the site and saw some things that made it seem unfit for purpose as an ereader. I made my comment because I was interested in hearing your impressions if you were using it as a daily driver.
I updated my original comment to include some more personal blogs with first-hand accounts. They're not mine but worth linking to for others!
I haven't bought a PineNote yet, but it's probably going to be my choice for that size of Tablet. I opted for a Xteink instead and have been very happy with it.
> Personally I view stuff like this as a nice-to-have, not a must-have. If it means I can't have an interface where I can buy books and then download them to my ereader, or I can't have an iphone app where I can read books and have my progress synced between my ereader and my phone, or it's unstable, or the battery life isn't good, then I would rather go with the Kobo. I understand that different people have different priorities, but those are mine. Stuff like this is why I'm interested in hearing more detailed information about what exactly the tradeoffs are for going with something like the Pinenote.
I agree that there are certainly a lot of sharp edges to less supported platforms. I just think I'd rather get a Boox (and deal with Android/Graphene) or PineNote over the Kobo over the long term. Then again, my usage of very simple -- maybe I just don't read as much/depend as much on the ereader to the extent that others do!
> I think you can still sideload KOReader on them, but that's a shame that they're making it harder to replace the stock OS entirely. I hadn't heard about that prior to now so thanks for bringing that up. I only have a Sage I bought a few years ago.
Ah yes, AFAICT what you're saying is correct -- sideloading apps is not an issue as far as I could find, it was just the inability to have custom firmware/OS.
I was very disappointed in this, and I generally see it as a step towards locking down that will only continue. Would love to be wrong though as I was very very convinced I wanted a Kobo Libra Color earlier).
People that are happy with the Kobos as they are (and the bundled software/services) I'm sure will be happy to keep buying though, I think the market is certainly big enough for that!
I mean, it’s expensive, huge, and potentially unstable; not exactly what I’d want to read in bed at night.
The Pine projects are necessary and well-motivated, but the PineNote doesn’t strike me as a reader’s device, maybe a hacker’s or someone that wants an e-ink tablet.
Kobo is actually in the process of completely rewriting their e-reader software (you can download the beta in the EU), and I’m pretty sure it’s no longer based on RMSDK. Adobe basically handed the EPUB DRM market to LCP on a silver platter by being a poor maintainer and then selling off to a third party that had botched the migration and further angered end users and platforms, that are switching off Adobe faster than ever
Only in EU because of the Accessibility Act[1]. Copywrong holders are allowed to disable screen readers elsewhere because that allows them to sell more audiobooks. You will apparently also lose many other features, among them Asian scripts and developer mode.
I’m not in the EU so I have not, this is based on the technical changes mentioned, and what I’ve heard from people. Feel free to try if you are in the EU: kobo.com/update
> When I started out, I dreaded the moment when I hit the validate button on my finished book after months of work, because it would always find something to cry about.
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.
Which, to be fair, overall probably still saved quite some time. The compile times alone would've meant they wasted so much more time by repeated earlier checks.
Whether a looming deadline changed the perception about that, we don't know ;-P
Be happy your readers use an ePub reader that supports (or at least, ignores) something like `max-width` in the first place :-P.
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).
It's already bad enough that HTML/CSS barely works in the target web browser environment, I don't see why anyone decided it was a good idea to use it for books.
I've often thought about figuring out a subset that operates fast on any computer and sticking to that for any web pages I make. If someone figured that out for epub, it would make it much, much more useful.
Ah, yes. When I paint, I also leave the middle unpainted, in case some people have a crack in their glasses that would make the painting look weird. Or maybe we should tell glasses makers to make better glasses and let the artists make their art.
I understand the frustration of the author but how many readers do have an old, unupgraded, maybe unupgradable epub reader? If authors want to make their work available to all readers they have to build for the least common denominator. If it happens to be something from 2013, sorry but that's the reality of the market.
I recently was in the market for a new e-reader and steered away from Kobo and Kindle because of their non-free ecosystem.
I don’t know how exactly it would negatively impact me but I didn’t want to find out.
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.
I don't really have an issue with kindle, I just download anything off of z-library and use the email to kindle tool. I haven't given Amazon a penny other than from the original purchase of the kindle. I only have used epub/pdf (and will never have a need for another format).
When using Kobo readers, using Calibre and Kobo utilities, which transparently "upgrades" your ePUBs to KePUBs without altering the copy on your disk is a must, and a huge win.
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.
When building EPublish ( https://frequal.com/epublish/ ), an HTML-to-epub converter, I faced similar hurdles. Trying to keep compatibility with numerous e-readers built with different stacks and varying degrees of EPUB versions is frustrating.
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.
If you use a kobo you have to give koreader a whirl! The only thing missing for me is the unified view of the library: koreader requires you to navigate to the subdirectory to open your ebook whereas nickel (kobo’s UI) will list them all in one library regardless of how deeply nested they are.
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.
> Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!
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.
epubcheck is meant to ensure conformance with the standards, not the interoperably implemented subset of the standards. (Which has lots of awkward questions: which implementations of the standards, which versions of those implementations, etc.)
The user wants the website to work in IE6, developing and testing only against IE6 to the detriment of other browsers is not generally regarded as a healthy state of affairs.
The standard exists, it is the responsibility of both the producer and consumer of ePUB files to adhere to the standard.
If a large fraction of your users are on IE6 and you can't realistically get them off it, you need to make sure your site works in IE6, and good tooling should help you do this. Of course you also want to make sure it works in other browsers your users use, and a standard may be helpful in doing that.
No, the users need to be able to check for conformance. What we also need is for vendors to supply test platforms. Amazon, to its small credit, does this, which is good, because the subset of html/css they support is limited and poorly documented. Heck, I'd be happy if Apple, Kobo, and everyone else just kept good documentation and up to date!
Though these days I have to spend more time worrying about EAA and ADA compliance than anything else.
A compatibility linter is a poor substitute for a vendor-supplied test platform, but if the vendor is uncooperative it may be the best that can be done.
"Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!"
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.
For my free novels which I deliberately keep the styles to header2 and body text, it is surprising the amount of crud that all the ePub conversion softwares generate, especially since they are just zipped web-pages.
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.
Yes, for the ones I've owned rooting is very easy. KOReader and Plato are both popular (amongst the community of eReader rooting people) alternatives to the OEM software.
Every Kobo reader is capable of running KoReader ( http://koreader.rocks/ ). That's the first, and probably last, step I'd take to render a book that the default reader takes issue with.
Search around, there's surely a way to break the drm. When theres no better way that's what I do too: pay for the book, convert to plain epub.
The publishing industry never got its head out of... some dark place. We've been able to buy mp3s without drm for ages, but somehow books are different.
If you have a ACSM (the file type Adobe Digital Editions uses for DRM) I’ve been using https://www.acsm-converter.com to strip the DRM and return a standard epub
"EPUB is an amazing open standard for ebooks, and yet so many implementations of it are just fundamentally flawed, all in the name of keeping IP lawyers happy."
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...
The author says that "In a perfect world, RMSDK would just stop living in the CSS stone-ages or at least provide some kind of error handling instead of dropping the whole book, but I’m not holding my breath."
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.
ePub compatibility issues are one of the worst parts of having a Kobo reader. I genuinely miss my Kindle and its simple but reliable MOBI format. At least there everything worked
I don’t miss my kindle, at all. Its text layout engine was a joke (every page edge was ragged!), you depend very heavily on amazons goodwill to keep allowing you, the device owner, to sideload your own books, it’s getting harder to install third party software, and well that one is personal but it’s from Amazon.
I’ve switched to kobos (Clara HD) and I’ve had to for years. It’s chugging along (had to 3d print a replacement power button a couple months ago), I can run koreader no problem and use calibre with the kobo plugin. And the default rendering engine in kobo’s firmware does actually typeset the text: no ragged edges!
The TLDR version is Abode supports backward compatibility ... and epub - * International Digital Publishing Forum* - is playing with a sprawling mess opting for the race to the top newest standards ... that always works so well and ensures the user base is always upgrading.
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.
To be clear, ADE’s behaviour is not conforming to any version of the standards it claims to implement. If it had been, it would reject that specific max-width property declaration as having an invalid value and ignore it, not reject the entire document: every single version of CSS has required that forwards-compatible behaviour.
PDF is not somehow immune to this either — a non-conforming implementation could similarly break what are meant to be forward-compatible extension points by raising an error on an unknown stream or object instead of (as required by the standard) ignoring it.
So if I understand correctly a struggling epub viewer or ADE should skip css that it considers malformed - which means the reason my viewers have considered a epub to be not able to be viewed / corrupt / whatever it is for some other reason than more recent / current css implementation.
PDFs certainly can suck, more often those that will only work with abode's software and other viewers I've tried can not.
While plausible, I would suspect it’s more likely you’ve just run into bugs than forwards-compatible error behaviour — most ePubs don’t get anywhere near actually interesting CSS!
An epub is just a plain html webpage compressed into a zip and its extension changed from .zip to ".epub". Assuming you have a web browser, you have something that will almost certainly render your epubs contents.
PDF is not nearly as pleasant under the hood. It's down right lovecraftian.
The lovecraftian horror of pdf mostly comes into play through the sheer amount of software that supply almost correct pdf. It's not enough to be able to read pdf anymore, you also have to be able to deal with software that emits subtly wrong documents.
I'm aware thanks. Mostly it's just my preferred viewer is older than css4 but it's been nice to find out why that was the case.
PDFs can be painful as well, more often it's then using abode's pdf viewer, but it's far less common for me. There was a time many years ago when I understood PDF structures better, back when I chose to manually edit and fix a couple of malformed PDFs.
I think its one reason ive been happy with software based epub readers where upgrading is usually reasonable to do. Either on my phone or android based eink reader. That said if they change too much then yea nobody will produce the new standard and only support the old one if it isnt carefully designed for graceful degredation.
>but it can’t validate CSS against a renderer which is fundamentally broken!
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.
You are of course correct that ePub nowadays doesn’t mandate a given version of CSS (though earlier versions did!), but that doesn’t matter in this case: it’s non-conforming according to even CSS level 1 (1996), per https://www.w3.org/TR/REC-CSS1-961217#forward-compatible-par...
> illegal values, or values with illegal parts, are treated as if the declaration weren't there at all
So a conforming implementation would ignore that max-width property declaration, not raise an error.
And those earlier versions of ePub which defined a required subset of given CSS standards? The forwards-compatible parsing rules were part of their subset.
No, the CSS spec is specifically designed to be forwards compatible because of exactly this issue. Any invalid CSS rule should only cause that specific line to be ignored, not the whole stylesheet. And certainly even if your CSS parser chokes in some specific case, it shouldn't cause your ereader to fail to load the entire book!
I don't like .epub. I understand the reasons why this format exists, and I am 100% behind those reasons. But it's because I don't find any EPUB readers appealing to me. Just give me a FoxIt Reader clone for .epub, that's all. But naaaah!!, every single fucking e-pub reader that I tried must be a fucking library collector instead, like it's 2000's Windows Media Player style. I hate that.
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.
As someone who loves FoxIt reader, I'm building https://merrilin.ai to be the best damned ebook reader out there, to support PDF and epub. FoxIt's annotation system is one of the best I've experienced and I want to design one that is just as good if not better.
Building a robust annotation system for both PDF and EPUB is a tough technical challenge, but definitely needed.
I've been working in a similar space and recently open-sourced it. It's a local-first 3D library for organizing and reading EPUBs and PDFs directly in the browser.
It's called KoreShelf on Github
Wow. This brings up some (bad) memories of working with an .epub export about 10 years ago. We had some embedded fonts to work around some poor rendering in some of the readers we tested, but some of the readers ignored the fonts altogether, causing the content to render boxes (bangs head on table)
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)
Adobe has always been like this, too. They squandered an enormous marketshare with Flash because the alternative would've been spending a couple million on QA and they managed to unite all of the browser manufacturers in agreement that the web was better off without such an unreliable partner.
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.
Love or hate Steve Jobs, his insistence of not supporting Flash on the iPhone (in favor of HTML5) accelerated Flash's demise dramatically.
The best feature of flash was that it was so easy to disable. Because 99% of the use was annoying ads that pinned your cpu at 100%.
And that was Jobs argument, that it was too resource intensive. Predictably though, now that annoying crap moved to "newer" tech (javascript) and now we can't disable it as easily or without as little consequence. Just as resource intensive though...
I never bought the benevolent technical angle for not supporting flash. I'm pretty sure Apple strategists knew the value of the gate-kept platform, the app-store revenue stream.
The pivotal point was that flash would break this stronghold by allowing rich applications that are reasonably self-publishable. (Excuse me while I go rinse that sentence out of my mouth)
First iPhone didn't have support for 3rd party apps. Steve Jobs even explicitly spoke about wanting to have all 3rd party things run in the browser.
Only when jailbreaking and custom apps got very successful, Apple introduced official app support and the appstore.
I think the Appstore was planned all along, just did not fit in the first release, so they adapted the launching narrative to: "the browser is enough for all 3rd party software".
No, Steve was very vocally against it until jailbreaks forced the issue. It’s well documented.
Vocally public yes… but they wanted to see what the diy scene created, how the power users were using the device and letting them develop the ideas and implement… they would open up and co-opt… boss tools is your drag down for all your settings case in point. This has been openly admitted to in interviews after the fact.
They 100% did not let the power users and DIY scene exist. It only existed by exploiting OS security vulnerabilities. Every new iOS release required finding a new way to crack it. That's why a lot of people chose Android.
[citation needed]
Apple didn't even have an AppStore in mind until people started hacking apps onto it.
Remember back in 2007 when Apple first told developers that to develop for the iPhone, they’d need to build WebApps for Safari? Well, that really was the plan. At the time, Jobs said:
The App Store came later and apparently as a reaction to jailbreakers and developer backlash.https://9to5mac.com/2011/10/21/jobs-original-vision-for-the-...
Jobs hated Adobe:
According to the biography, Jobs’ longstanding animus toward Adobe helped form his vision for Apple’s tightly controlled mobile environment.
In 1999, he was flatly denied when he asked Adobe to create a version of its popular Adobe Premiere digital-graphics software for the Mac. Adobe also wouldn’t rewrite Photoshop for the Mac’s operating system, even though Macs were popular with designers.
“My primary insight when we were screwed by Adobe in 1999 was that we shouldn’t get into any business where we didn’t control both the hardware and the software, otherwise we’d get our head handed to us,” Jobs said, according to Isaacson.
The two companies go back together even further. Apple invested in Adobe in 1985 and they worked together early on. But Jobs, who in Isaacson’s book comes off sometimes as vindictive and brusque as he was innovative and inspirational, told Isaacson that Adobe went downhill after founder John Warnock retired.
“The soul of Adobe disappeared when Warnock left,” he said. “He was the inventor, the person I related to. It’s been a bunch of suits since then, and the company has turned to crap.
https://edition.cnn.com/2011/11/09/tech/mobile/flash-steve-j...
I remember seeing stories about Adobe not being able to, or not wanting to, write a good energy efficient flash renderer for the iPhone, thus being another reason not to support it for Jobs (Adobe being of the mind that "Flash is so big, they'll have to support it" and Jobs proving otherwise)
They also either could not or would not write efficient Flash clients on Mac OS or Linux, while the Windows version was fine.
I bounced around a lot between the three OSes at that time, and Flash was bad enough on the other two that I would almost automatically reach for Windows when I had to use it.
It took them years to realize that the App Store could be a thing.
and now they make probably insane marketshare on the AppStore alone.
> Apple today announced the global App Store ecosystem facilitated over $1.4 trillion in developer billings and sales in 2025
https://www.apple.com/newsroom/2026/06/app-store-ecosystem-r...
Then again, they chose to use those exact words in their webpage, so you decide how large a grain of salt to take.
> I never bought the benevolent technical angle for not supporting flash.
Why not? Flash was objectively an awful experience on mobile, and the iPhone was entirely about good UX.
> I'm pretty sure Apple strategists knew the value of the gate-kept platform, the app-store revenue stream.
Initially the iPhone didn't even have an app store. They wanted everyone to make HTML5 apps.
There was also the argument that "We also know first hand that Flash is the number one reason Macs crash"
Flash had many issues for sure, first and foremost security. But I can’t help but feel sad of what was lost since then. The Flash era produced some really unique experiences on the web.
it was about as unique as seeing corn in my poop sometimes.
The JimCarrey.com website was cool. That's about the only flash thing I came across that was though. Now gone as a site but recorded on video https://youtu.be/B1XZixLBurQ I'm not sure you can do those things in javascript to this day?
Lot of it was bad, sure, but there was so much games and animation done by literal kids back then, because of how easy it was to create something with the tooling. Nothing even come close today, unfortunately.
Sounds like you didn't experience all the awesome flash games and animated videos etc that people made.
And now were back with WebAssembly, WebGL, WebGPU, targeting 10+ year old graphic cards, without comparable easy of use tooling.
Those that think using Godot or Unity is the same, never did Flash games.
Flash was better back when it was called VideoWorks. ;)
Notably, there was also a MusicWorks. Both Mac-only. But like EARLY Mac-only.
/dates me
"Please buy the next version to see if we fixed your bug?" is peak Adobe.
> heisenbugs
gold
A well-established term of art dating to 1983:
<https://en.wikipedia.org/wiki/Heisenbug>.
Gold, but not new gold: http://www.catb.org/~esr/jargon/html/H/heisenbug.html
I also learned this term pretty recently, loved it. Another fav tech term is automagically :-)
I'm guessing you are very young!
Fnord gold
23 skidoo.
Fnord Knox
Flash is still unsurpassed as the easiest publishing medium.
JavaScript build system layer cake and "web standards" are a million times harder than just drawing some stuff, maybe writing a simple function, then building a static file that can be embedded anywhere and even downloaded. You have to spend so much time setting up any flash alternative, and the "standards" are worse.
I hate Steve Jobs for killing Flash and Adobe for being such awful stewards of one of the most amazing web technologies.
Kids growing up today have no idea how magical Flash was. It was like Roblox or Minecraft for web.
Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power. And none of its ease.
Magical? Those are some rose tinted glasses. Having to install a binary blob from a free-software hostile vendor that wanted a monopoly to load a website was always ridiculous ask. Flash was a constant embarassment of RCEs vulns and virtually non-existent Linux support.
I remember the time of browser plug-ins (not “extensions”). Everyone happily installed Flash, and the Crescendo midi plugin, and multiple other in-retrospect-ill-advised plugins to enable fun stuff to work in their browser.
The “everyone hates Flash” stuff came later. It served a purpose for quite a while and people loved it. Newgrounds was a place of magic.
FYI, just cause I discovered this recently and I was mildly mind blown: newgrounds is alive and kicking with new stuff.
I do miss kongregate tho.
I mean, flash was always a pain in the ass, even when you got it working. The animations and games were great and I'm a big fan of stuff that tries to make it easy to publish programs like that, but I was still a teenager when apple announced they weren't supporting it and I was genuinely happy because I was so annoyed using it even on a windows pc.
> Having to install a binary blob from a free-software hostile vendor that wanted a monopoly to load a website was always ridiculous ask.
The entire browser ecosystem started out closed source. Even JavaScript was written to interact with closed source Java Applets.
> Flash was a constant embarassment of RCEs vulns
Browsers still are the goto target for contests like Pwn2own. It is almost like inviting the entire world to run untrusted code on your computer is not a great idea, no matter how many security buzzwords browser makers like to throw arround.
> The entire browser ecosystem started out closed source.
That is completely, 100%, untrue and not remotely historically accurate. WorldWideWeb (the first web browser) was public domain. Lynx came out in 1992. Mozilla was open sourced in 1998. There was never a time when the "entire" browser ecosystem was closed source. It certainly didn't start that way.
> Even JavaScript was written to interact with closed source Java Applets.
No, it wasn't. From WP (https://en.wikipedia.org/wiki/JavaScript):
> Netscape decided to add a programming language to Navigator. They pursued two routes to achieve this: collaborating with Sun Microsystems to embed the Java language, while also hiring Brendan Eich to embed the Scheme language.
> The goal was a "language for the masses", "to help nonprogrammers create dynamic, interactive Web sites". Netscape management soon decided that the best option was for Eich to devise a new language, with syntax similar to Java and less like Scheme or other extant scripting languages.
> [...]
> The choice of the JavaScript name has caused confusion, implying that it is directly related to Java. At the time, the dot-com boom had begun and Java was a popular new language, so Eich considered the JavaScript name a marketing ploy by Netscape.
Some people might have used it for the purpose you claim, but that's not why it was invinted.
> Netscape decided to add a programming language to Navigator. They pursued two routes to achieve this:
And the reason for that two language approach is given in the linked source:
> We aimed to provide a “glue language” for the Web designers and part time programmers who were building Web content from components such as images, plugins, and Java applets. We saw Java as the “component language” used by higher-priced programmers, where the glue programmers—the Web page designers—would assemble components and automate their interactions using [a scripting language].
Earlier sources clearly state that Java was intended as the primary language and JavaScript merely acting as glue.
Yeah but we were kids, we didn't give a shit about any of that. Kind of still don't give a shit about any of it tbh. There's security holes in everything anyway.
The overwhelming majority of computer users simply DO NOT CARE about things like "install a binary blob" or "free-software hostile vendor" or "non-existent Linux support". They installed the plugin and got a way better experience.
> Flash was a constant embarassment of RCEs vulns
I wonder if anyone has done an analysis of Flash versus Javascript (or other browser technology) vulns over their respective lifespans.
If Flash hadn’t sucked harder than a neutron star, that would be an argument to have. People install lots of proprietary plugins today. Flash would’ve been just one more on that list.
But it did suck, and badly. It crashed the browser all the freaking time, often hard enough to crash the whole OS. (“But the OS shouldn’t let that happen!” True, although even with that said, it was in the short list of common apps capable of crashing that badly. It was almost a talent.)
Flash was horrid. While idea was fine, the implementation was terrible. No mobile OS could have run it solidly and without sucking batteries like no tomorrow. Flash in the right hands could have been nice. We’ll never know because that never happened.
> No mobile OS could have run it solidly and without sucking batteries like no tomorrow.
By the time mobile could run Flash, it was too late. Between Apple & Adobe, it had no shot of making the transition. But before that, Flash was pretty amazing.
It was never amazing. It was adequate to give creative people a way to work around its many shortcomings and make something cool anyway. The tech and the implementation was awful, and all credit goes to people who still managed to shine through it.
For all the many reasons people might dislike Apple, they were 100% in the right on this topic. Flash needed to die. It got everyone to collectively push the web standard technologies ahead into something way, way better.
> The tech and the implementation was awful, and all credit goes to people who still managed to shine through it.
Sorry, that's simply not true. The tech was ahead of its time. The implementation was intuitive. Only developers and Steve Jobs hated it, because Flash made it way too easy for anyone to make something fun.
Also anyone who gave two shits about security hated it because it was a security nightmare. Don't leave a hater out.
And yet, there was no html5 newgrounds. The magic of flash was that it gave a space where a music person, an art person, and a programmer could bang something out. The barrier to entry was comically low, which allowed an absolute explosion of content.
Sometimes good products happen despite bad technical foundations.
> And yet, there was no html5 newgrounds.
Let me introduce you to itch.io[0] where, in fact, people bang out HTML5 games at a rate that will stagger your eyeballs.
(Even me, a resolute "backend-only" dinosaur managed to use a HTML5 game engine to knock something out playable in an hour or two.)
[0] https://itch.io/games/platform-web - ~689k results
> Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power.
Is this a troll? What could an application do with Flash in 2005 that we can't do with a modern web application today (excluding the obvious answer of runtime vulnerabilities that allowed apps to escape the sandbox)?
> What could an application do with Flash in 2005 that we can't do with a modern web application today
Show me the JavaScript framework (or tool that exports JS) that you can give it to a middle schooler and have them make a cartoon with audio and moving images that they can draw themselves, while responding to user input. Have the exported artifact be consistent across all major operating systems and browsers.
Yeah, Flash was never replaced
https://threejs.org/
https://scratch.mit.edu/
Flash had its problems but as a user, it looked sharper and smoother than even current websites. And its editor gave non-tech users ability to create amazing animations, interfaces, and even games.
wasn't some of that smoothness because it ran at a 100hz tick without any way of adapting it (and still running existing code)? That was the complaint I kept hearing from people attempting to make flash on phones viable (this led to ludicrous battery consumption)
It could be smooth AF in ways that a video on a service like YouTube never could be.
I didn't get into flash games at all, but I used to watch Flash animations.
Like, for instance, Salad Fingers: https://archive.org/details/flash_salad-fingers
This was intended for a slow 2004-era computer with a 4x3 (probably 1024x768) display, where it worked very well.
But it's not 2004 anymore; things are much faster and screens have gotten a lot bigger. Here in 2026, Salad Fingers renders out fine at higher resolutions, and at different aspect ratios. It works great on my desktop at 1080p, without stretching [and with some probably-unintentional extra content on the sides]. It even works on my pocket supercomputer's 3200x1440 20:9 display.
Vectors are fun, and they scale as technology improves. The lines remain smooth and defined. And with Flash, that's a built-in: An unaltered 22-year-old digital animation still looks crisp.
For contrast, if Salad Fingers had been published on YouTube way back around that time, it would have been in chonky fixed-pixel 320x240. Maybe that would be as good as it would ever get unless it were rendered and uploaded at higher resolutions later.
Image-wise, SVGA + JS probably gets you the clarity. Standard gif / image animations not so much, if that's what you're referencing.
This isn't my baliwick, so I've absolutely nothing to say about the ease with which these options can be created.
what’s he is referring is the editor and the easy way of drawing things, still agree we can do things today but a easy to draw editor like that is missing. I was a fan of flash and fireworks.
The editor was a scripted timeline, similar to a video or animation timeline. It was fantastic for creatives, but counterintuitive for programmers, so most devs hated it.
There was more unique content/UI in the Flash era.
This went away not only because flash died, but also as the internet commercialized.
I mean, consider this: McDonald’s used to be fun and colorful. Now every McDonald’s is boring and gray. And, wait, every store is boring and gray! And flash had nothing to do with that.
You'll get hammered for this on HN, but the web was magical and weird with Flash around, and now it feels quite vanilla and boring. I long for the days of weird experimental art and goofy animations and bonkers UIs.
It was a fun and experimental time for sure. Way more stuff was weird in a good way. Standards hadn’t settled. All kinds of fun stuff was created in Flash that could not have been built with the standardized web tech of the day. I don’t really miss Flash but I do miss the early internet sometimes and Flash was part of that. (Remember when it was FutureSplash?)
I would be remiss if I didn’t post the most early-Internet-type thing I’ve encountered in a long time. Dungeon Soup.
https://m.youtube.com/@DungeonSoup
Once upon a time this would have been my favorite Flash cartoon series.
“Season one” playlist: https://youtube.com/playlist?list=PLSq76P-lbX8Ws6vgAAC2WhwSu...
I would rather say, that now the web feels like being handed turds at every turn, and needing to wear a hazmat suit, if one wants to stay clean. Not what I would call boring. More like infuriating.
Yeah but the execution still mattered. I'm a Flash / Shockwave fan as well but there's no point pretending that package was sufficient for the job it was pitched to do. Macromedia seemed to be on a really good track with Shockwave and Flash, but either didn't set up the technology for internet success, or really just sold out the goods with the Adobe acquisition.
In any case, take heart though. If we did it once, we can do it again.
But we won't because this isn't something that can be done by consensus or by an ad company.
What I never understand is why we never got a Flash-level authoring tool that exported to modern JavaScript/Canvas. Ruffle shows it can be done.
Adobe could have retuned Animate to do it, but instead let it languish as a niche animation tool for some animation studios to use before trying to kill it.
Those downvoting you have no idea of what you are talking about. Flash was what truly brought multimedia to the internet. You could make complex vector animations so easily in it, and it would only take a few minutes to load on a dialup or ISDN because of its small size (10's or 100's of KB). At one point, it used to power the whole of Youtube (and many other video sites). "Web applications" in this era actually meant something built with Flash. And it did all this on ancient hardware. Flash used to run on 90+ % of internet connected PCs at one point if I remember right. And because of that, you could count on Flash player more than the browsers they ran in. Adobe 100% screwed it up.
I would think:
1) macromedia ->
2) adobe ->
3) steve jobs
I think 2 was the root cause, not #1 or #3.
https://web.archive.org/web/20170615060422/https://www.apple...
That said, I wonder how easy it is to publish on apple? I think of xcode in sort of the same way sj complaining about adobe being cross-platform and slow.
You know you can use Ruffle if you really want Flash right?
https://ruffle.rs
But the only standard you need is WASM. All browsers support it. Use whatever you want to make it. In fact, Ruffle is just a WASM app.
The problem is that, while there's no theoretical barrier to an authoring tool with a Director-like user experience that exports to Wasm, no one has actually written one, and it's not a small amount of work.
(I agree that we're better off without Flash, but this particular problem is real and unsolved.)
Or you can just use PaleMoon browser ( https://www.palemoon.org/ ) and install the original Flash player plug-in in it.
Ruffle is not complete or comprehensive. In my test of a dozen swf ruffle could successfully display about half. Compare to the actual flash plugin Shockwave Flash 11.2 r202 (11.2.202.643) in my retro machine browser which displayed them all perfectly.
What about lightspark?
htps://lightspark.github.io
this is unfortunately, the most revisionist take I can imagine. I don’t mean this in a personal way, mind you but while it may have been magical to publish interactive websites, using flash, that magic is utterly outweighed by the mundane vulnerabilities that flash was riddled with.
It’s safe to say we all miss sites like Homestar runner, and I had a co- worker who generated many meme – worthy flash presentations of his coworkers, which were hysterical. however, flash generated security vulnerabilities on the daily, and unfortunately, these vulnerabilities were very conveniently cross platform. These vulnerabilities, which Adobe couldn’t, or wouldn’t, resolve resulted in many many lost hours fixing virus – and Trojan horse – infested PCs, Macs, and cell phones. Adobe never managed to sandbox flash at all.
I miss a lot of old flash content, and I’m sure many people miss the ease with which you could create interactive content for websites. The fault here lies squarely on Adobe, who wouldn’t fix the situation.
Compared to the best that someone can vibe code? Not to show my age, but we were kids when flash came out. That copy of macro media? I don't know about you. We spent hours and hours and hours with that spend hours and hours and hours with vibecoding and tell me that you really can't accomplish similar shit. Then you just to deploy it you and I might be to smart to just paste your Vercel API key in ChatGPT, but pretend you're 16 right now.
I can tell you how much tsc sucks off the top of my head but what I can't do is tell you to hit ctrl+enter in Claude desktop to play movie.
What kids know today is how magical Claude desktop and ChatGPT are. The deploy story is trivial. just give the AI the key. We can judge someone for being dumb enough to do that, but unless you're selling consulting services, it's not nice to laugh. if you are selling consulting services then let's talk sales channels lol
Yes compared to vibe coded stuff too. And it costed less money.
> "Websites are still inferior to Flash of the early 2000s. It's taken decades and they can only mimic a fraction of its power. And none of its ease."
Somewhat mirrors my experience with all those rubbish non-PDF formats for digital document publishing, e. g. ePub: Often terminally ugly and utterly useless on top of it (not properly citeable, et cetera).
As someone who has spent a good deal of time trying to build ereader software, eventually I decided to try to deal with the devil and build on top of RMSDK.
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.
I used the FBReader app to read a ton, they make their SDK available for other apps to use.
The last time I looked into this, readium lcp drm wasn't something US publishers were comfortable distributing their titles with, although it seems like this may be changing, which is good insofar as readium is at least open source and free to build with.
Hello, I'm building https://merrilin.ai, could I pick your brain about the problems you faced?
Sure thing. I've actually been working on the spoiler-free resource angle as well. I can book a call to talk. Distribution is the killer problem here though.
I thought about building this too! Love that both of you are pursuing it as I haven't had the time to start. Don't give up.
Yay! Registrations to https://merrilin.ai are open and you can enjoy a free account for as long as I can afford to give it (I have no funding lol). The android app is ready for closed testing too, if you have an Android device, mail me at mail [at] stonecharioteer.com and I'll add you to the beta testing. ios is still a pain.
Why don't you do sign in with openrouter oauth, then users can create an account and assign a key to your app, with spending limits. It's trivial, plus if you get a decent amount of users your app will appear on the leader board and that's free marketing for your project.
https://openrouter.ai/docs/guides/overview/auth/oauth
That's a good point, but our harness right now is very fine tuned towards kimi2.6, it's something we want to improve but it's just 2 broke dudes working on it right now.
You don't have to give them a choice in the model, you can set your app to use kimi 2.6 only.
Yay! Please do, or email me at mail [at] stonecharioteer.com
AIUI, Kobo devices have a more advanced rendering engine if you name the file with .kepub.epub. (I think it's based on ePub 3?) Not sure if it would fix the problem here. But I personally run ePubs through kepubify (https://pgaskin.net/kepubify/try/) before transferring them to my Kobo.
Yes, I do that for everything too. Also publishers like Standard ebooks provide a kepub download - as they explain here they have problems with the Adobe reader too. https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
I love my Kobo (clara colour) and really, if they just removed the Adobe reader, it'd be perfect. And yes, I've tried KOreader, but never switched to it because I like my Overdrive library books and Kobo Store.
Looks like this info was added to the post as an update.
Unfortunately, epub and epubcheck isn't the great uncontroversial resource the author makes it out to be. When W3C, Inc. took over maintenance of the EPub spec around when 3.1 was current, they just referenced WHATWG HTML and other ever-expanding browser specs ([1]). Being "living standards", these have no versioning or QA. As a consequence of being based on a version of HTML that redefined headers and sectioning, Epub 3.2 just made existing epubs non-conforming. Which is why Calibre and other tool still recommend 3.1 or better yet 2.
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
Yes, it is widely known in the epub space that targeting 3.1 or 2 is the more sane option.
With EPUB compatibility issues CSS should always be suspect number 1. Using "modern" CSS features and complaining about missing flex boxz grid, etc is a web developer's mindset.
Just because EPUB shares some of the stack with the web doesn't mean they perfectly overlap (or even should).
Hardly any e-ink embedded e-reader devices use a browser for rendering, they all use purpose built HTML/CSS parsing and rendering toolchains, are baked into firmware and updated once in a blue moon. (If you're interested look at koreader's crengine or Crosspoint reader which runs on an ESP32!)
The blog post reeks of overly confident AI prose. But don't be fooled.
Shouldn't a CSS engine just ignore directives it doesn't know? At least it shouldn't fail without an error.
Came here to say exactly that: CSS was designed to be friendly and just ignore any line it doesn’t understand. It’s the whole point of browsers and progressive improvements.
Are we blaming the spec and the author of the post for trying to conform to the checks, instead of blaming Adobe or Kobo for using 16-year old technology that ISN’T spec-compliant? -.-
BTW for those who are looking for a device, the PineNote exists:
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...
Have you tried the PineNote yourself? It $400 and says that it's "aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux." The community provided firmware they link for it hasn't been updated in over a year.
The Kobos don't limit what you can do with them either, you can sideload alternative e-reader software like KOReader that improves on the built-in reader functionality.
I have a PineNote but also (had a Remarkable 1 a while ago) a Remarkable2 and RM Pro. I also gifted a PocketBook Verse Pro and installed Koreader on it.
Basically if you want a "product" to use right now and still want to tinker, RM gives you ssh access to a system you can tinker with. RM2 has the best community support for now though.
PineNote works... but yes you will have to be ready to tinker. It's heavy and think but powerful, all the way to having a browser, audio, microSD, etc.
Meanwhile the PocketBook Verse Pro just works, no tinkering, but also tiny and not get for sketches IMHO.
Can highly recommend the pocketbook. If you just want to read i think it’s the best option and a fraction of the price of pinenote
Exactly, if you don't enjoy sketching concepts, think via diagrams or need to write in order to think then a PockerBook is good enough.
If, like me, you clarify your thoughts by physically writing (not typing) or sketching, then the ability to do so without distraction, moving a piece of text of the page, changing the position of a box in a complex diagram... then it's definitely worth the price IMHO.
> 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.
This note was in the original comment, did you read it? The fact that it is $400 (more expensive) and has less out of the box software is literally mentioned to alert people to that.
> The Kobos don't limit what you can do with them either, you can sideload alternative e-reader software like KOReader that improves on the built-in reader functionality.
This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development:
https://www.mobileread.com/forums/showthread.php?t=363175
So much so that QuillOS which used to be Kobo focused rewrote to support the PineNote
https://github.com/Quill-OS/quill
https://quill-os.org/
The point is to buy hardware that is built for you to freely modify and fully own, from the start.
My post was to make sure everyone knew the PineNote was an option, because I certainly did not know it until someone on HN made me aware.
Could you maybe make your point more concrete? Are you attempting to completely dissuade people from using the PineNote because it may not be easy to side load apps to it on hacker news?. Obviously different people have different propensities to do hacking, and some may not be able to afford the PineNote due to how expensive it is, but it's not clear what the goal of your comment was.
If your goal was "invest in Kobo instead of PineNote", I disagree with that. I'm not interested in investing (whether money or time) in an ecosystem that is just going to rug pull me eventually, over nickels and dimes.
BTW for those who agree, another great option is XTeink -- very hackable, and I've bought one myself:
https://www.xteink.com/
And there's a Linux phone out there which looks pretty encouraging too:
https://furilabs.com/shop/flx1splus/
Graphene is likely still the easier more polished option, but it's great to have options these days.
> This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development: > > https://www.mobileread.com/forums/showthread.php?t=363175
Thanks for the link on mobileread. I was not aware of current development in direction of secure boot / chain of trust.
Not OP, but when I was looking for an e-reader, I looked up the Pinenote. I could not find easily a lot of information on its software state. I could find a lot on Kobo hacking. I notably found https://anarc.at/hardware/tablet/kobo-clara-hd/ and this motives me to get a second hand Clara HD for less than 100$. It was way cheaper than starting with 400$ and unknown software state.
> Could you maybe make your point more concrete?
I hadn't heard of the Pinenote before looking at your comment, so I looked at the site and saw some things that made it seem unfit for purpose as an ereader. I made my comment because I was interested in hearing your impressions if you were using it as a daily driver.
> The point is to buy hardware that is built for you to freely modify and fully own, from the start.
Personally I view stuff like this as a nice-to-have, not a must-have. If it means I can't have an interface where I can buy books and then download them to my ereader, or I can't have an iphone app where I can read books and have my progress synced between my ereader and my phone, or it's unstable, or the battery life isn't good, then I would rather go with the Kobo. I understand that different people have different priorities, but those are mine. Stuff like this is why I'm interested in hearing more detailed information about what exactly the tradeoffs are for going with something like the Pinenote.
> This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development:
I think you can still sideload KOReader on them, but that's a shame that they're making it harder to replace the stock OS entirely. I hadn't heard about that prior to now so thanks for bringing that up. I only have a Sage I bought a few years ago.
> I hadn't heard of the Pinenote before looking at your comment, so I looked at the site and saw some things that made it seem unfit for purpose as an ereader. I made my comment because I was interested in hearing your impressions if you were using it as a daily driver.
I updated my original comment to include some more personal blogs with first-hand accounts. They're not mine but worth linking to for others!
I haven't bought a PineNote yet, but it's probably going to be my choice for that size of Tablet. I opted for a Xteink instead and have been very happy with it.
> Personally I view stuff like this as a nice-to-have, not a must-have. If it means I can't have an interface where I can buy books and then download them to my ereader, or I can't have an iphone app where I can read books and have my progress synced between my ereader and my phone, or it's unstable, or the battery life isn't good, then I would rather go with the Kobo. I understand that different people have different priorities, but those are mine. Stuff like this is why I'm interested in hearing more detailed information about what exactly the tradeoffs are for going with something like the Pinenote.
I agree that there are certainly a lot of sharp edges to less supported platforms. I just think I'd rather get a Boox (and deal with Android/Graphene) or PineNote over the Kobo over the long term. Then again, my usage of very simple -- maybe I just don't read as much/depend as much on the ereader to the extent that others do!
> I think you can still sideload KOReader on them, but that's a shame that they're making it harder to replace the stock OS entirely. I hadn't heard about that prior to now so thanks for bringing that up. I only have a Sage I bought a few years ago.
Ah yes, AFAICT what you're saying is correct -- sideloading apps is not an issue as far as I could find, it was just the inability to have custom firmware/OS.
I was very disappointed in this, and I generally see it as a step towards locking down that will only continue. Would love to be wrong though as I was very very convinced I wanted a Kobo Libra Color earlier).
People that are happy with the Kobos as they are (and the bundled software/services) I'm sure will be happy to keep buying though, I think the market is certainly big enough for that!
Thanks, I'll look at those blog posts.
Also worth checking out, this guy's Open-Source 60hz e-ink screen: [video] https://www.youtube.com/watch?v=nHbA2-_qzH4
I mean, it’s expensive, huge, and potentially unstable; not exactly what I’d want to read in bed at night.
The Pine projects are necessary and well-motivated, but the PineNote doesn’t strike me as a reader’s device, maybe a hacker’s or someone that wants an e-ink tablet.
Thanks for this call out. I have not checked on Pine devices much since a disappointing early Pinebook.
No worries, and thanks for your service -- people buying possibly-disappointing early devices definitely enables the newer devices to exist :)
Kobo is actually in the process of completely rewriting their e-reader software (you can download the beta in the EU), and I’m pretty sure it’s no longer based on RMSDK. Adobe basically handed the EPUB DRM market to LCP on a silver platter by being a poor maintainer and then selling off to a third party that had botched the migration and further angered end users and platforms, that are switching off Adobe faster than ever
Only in EU because of the Accessibility Act[1]. Copywrong holders are allowed to disable screen readers elsewhere because that allows them to sell more audiobooks. You will apparently also lose many other features, among them Asian scripts and developer mode.
[1] https://www.kobo.com/kobo-writing-life/blog/our-commitment-t...
Have you tried the beta? Have you found it to be substantially better?
I’m not in the EU so I have not, this is based on the technical changes mentioned, and what I’ve heard from people. Feel free to try if you are in the EU: kobo.com/update
Interesting news! Though I'm on https://koreader.rocks/ like most people here, I suppose.
> When I started out, I dreaded the moment when I hit the validate button on my finished book after months of work, because it would always find something to cry about.
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.
Which, to be fair, overall probably still saved quite some time. The compile times alone would've meant they wasted so much more time by repeated earlier checks.
Whether a looming deadline changed the perception about that, we don't know ;-P
Adobe Digital Editions and RMSDK were recently sold to Wipro Engineering: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
Sold or outsourced?
> Wipro now manages and distributes any new updates, enhancements, bug fixes, and support requests directly
> Create your new ByteBooks ID using the same email address that you used for Adobe ID
Seems sold mostly.
'transitioned'
Be happy your readers use an ePub reader that supports (or at least, ignores) something like `max-width` in the first place :-P.
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).
It's already bad enough that HTML/CSS barely works in the target web browser environment, I don't see why anyone decided it was a good idea to use it for books.
I've often thought about figuring out a subset that operates fast on any computer and sticking to that for any web pages I make. If someone figured that out for epub, it would make it much, much more useful.
Ah, yes. When I paint, I also leave the middle unpainted, in case some people have a crack in their glasses that would make the painting look weird. Or maybe we should tell glasses makers to make better glasses and let the artists make their art.
People making shows for TV had to respect the TV ”safe area”: <https://en.wikipedia.org/w/index.php?title=Safe_area_(televi...>
EPUB: the open standard where "valid" and "will render correctly" are two separate hobbies.
I understand the frustration of the author but how many readers do have an old, unupgraded, maybe unupgradable epub reader? If authors want to make their work available to all readers they have to build for the least common denominator. If it happens to be something from 2013, sorry but that's the reality of the market.
I read this as saying a new Kobo in 2026 uses Adobe drm software that has css rules stuck in 2013.
I recently was in the market for a new e-reader and steered away from Kobo and Kindle because of their non-free ecosystem. I don’t know how exactly it would negatively impact me but I didn’t want to find out.
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.
I don't really have an issue with kindle, I just download anything off of z-library and use the email to kindle tool. I haven't given Amazon a penny other than from the original purchase of the kindle. I only have used epub/pdf (and will never have a need for another format).
Technically you already have need of another format, because Kindles don't support epub, and your books get converted before the transfer.
The "Send to Kindle" page only accepts ePub, as to whatever format is used internally I couldn't care less.
> that bloated pinnacle of software that is 80% about DRM, 20% about the reading experience
I have never seen someone explain the adobe software so perfectly. Using any adobe software is exactly this.
Unfortunately this is any reader software that deals with publishers who require DRM. IME, the vast majority of bugs also come from the DRM.
When using Kobo readers, using Calibre and Kobo utilities, which transparently "upgrades" your ePUBs to KePUBs without altering the copy on your disk is a must, and a huge win.
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.
When building EPublish ( https://frequal.com/epublish/ ), an HTML-to-epub converter, I faced similar hurdles. Trying to keep compatibility with numerous e-readers built with different stacks and varying degrees of EPUB versions is frustrating.
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.
If you use a kobo you have to give koreader a whirl! The only thing missing for me is the unified view of the library: koreader requires you to navigate to the subdirectory to open your ebook whereas nickel (kobo’s UI) will list them all in one library regardless of how deeply nested they are.
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.
Hot take: you don't need CSS in your book, a few of <style:'width: 100%;'> is enough.
If nobody is able to implement the standard it is probably not amazing.
imho for a standard epub there should be as little CSS as possible
I once read an ebook that was formatted by a guy who had only ever done magazines and it was a huge mess. 2 columns of text per page. No auto scaling.
The best ebook format I have ever experienced is .txt and just let the software figure out where the text needs to go.
Many ePub readers allow you to ignore formatting. And that’s exactly what I do.
The best format was fb2
> Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!
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.
epubcheck is meant to ensure conformance with the standards, not the interoperably implemented subset of the standards. (Which has lots of awkward questions: which implementations of the standards, which versions of those implementations, etc.)
The latter seems like what the tool's users actually want. That it's a harder problem doesn't change that.
The user wants the website to work in IE6, developing and testing only against IE6 to the detriment of other browsers is not generally regarded as a healthy state of affairs.
The standard exists, it is the responsibility of both the producer and consumer of ePUB files to adhere to the standard.
https://en.wikipedia.org/wiki/Robustness_principle
If a large fraction of your users are on IE6 and you can't realistically get them off it, you need to make sure your site works in IE6, and good tooling should help you do this. Of course you also want to make sure it works in other browsers your users use, and a standard may be helpful in doing that.
No, the users need to be able to check for conformance. What we also need is for vendors to supply test platforms. Amazon, to its small credit, does this, which is good, because the subset of html/css they support is limited and poorly documented. Heck, I'd be happy if Apple, Kobo, and everyone else just kept good documentation and up to date!
Though these days I have to spend more time worrying about EAA and ADA compliance than anything else.
A compatibility linter is a poor substitute for a vendor-supplied test platform, but if the vendor is uncooperative it may be the best that can be done.
It's not a direct substitute at all. It's not intended to be. And--it's on the vendors for making crap software and not keeping up.
I’m supposed to be able to lend ebooks from my local library. Adobe makes it impossible as their software doesn’t run on my macbook…
"Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!"
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.
For my free novels which I deliberately keep the styles to header2 and body text, it is surprising the amount of crud that all the ePub conversion softwares generate, especially since they are just zipped web-pages.
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.
Is there a way to root the kobo and put a modern renderer in place?
It runs a standard linux and mounts as external storage when connected over USB. No need to "root" at all.
Yes, for the ones I've owned rooting is very easy. KOReader and Plato are both popular (amongst the community of eReader rooting people) alternatives to the OEM software.
It's always CSS.
compatible style stuff
Every Kobo reader is capable of running KoReader ( http://koreader.rocks/ ). That's the first, and probably last, step I'd take to render a book that the default reader takes issue with.
As I understand it, KoReader doesn’t work with drm protected books which means I can’t use it with most books I buy.
Ebook producers really should be forced to either drop drm or adopt a cross-platform standard.
Search around, there's surely a way to break the drm. When theres no better way that's what I do too: pay for the book, convert to plain epub.
The publishing industry never got its head out of... some dark place. We've been able to buy mp3s without drm for ages, but somehow books are different.
If you have a ACSM (the file type Adobe Digital Editions uses for DRM) I’ve been using https://www.acsm-converter.com to strip the DRM and return a standard epub
BOOX works fine. One solution is to ask Codex to reformat your epub file before importing it to your ereader.
I love my Boox, I run Storyteller on it instead of the native e-reader. I love that it’s just an android tablet with an e-ink screen.
"EPUB is an amazing open standard for ebooks, and yet so many implementations of it are just fundamentally flawed, all in the name of keeping IP lawyers happy."
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...
The author says that "In a perfect world, RMSDK would just stop living in the CSS stone-ages or at least provide some kind of error handling instead of dropping the whole book, but I’m not holding my breath."
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.
Actually - in a perfect world steve jobs would have written a missive about it and killed it from orbit.
https://en.wikipedia.org/wiki/Thoughts_on_Flash
https://web.archive.org/web/20170615060422/https://www.apple...
ePub compatibility issues are one of the worst parts of having a Kobo reader. I genuinely miss my Kindle and its simple but reliable MOBI format. At least there everything worked
I don’t miss my kindle, at all. Its text layout engine was a joke (every page edge was ragged!), you depend very heavily on amazons goodwill to keep allowing you, the device owner, to sideload your own books, it’s getting harder to install third party software, and well that one is personal but it’s from Amazon.
I’ve switched to kobos (Clara HD) and I’ve had to for years. It’s chugging along (had to 3d print a replacement power button a couple months ago), I can run koreader no problem and use calibre with the kobo plugin. And the default rendering engine in kobo’s firmware does actually typeset the text: no ragged edges!
Death to Adobe. For this reason and 10,000 others.
I’m curious if simply running the original EPUB through Kepubify fixes the problem.
https://pgaskin.net/kepubify/
The TLDR version is Abode supports backward compatibility ... and epub - * International Digital Publishing Forum* - is playing with a sprawling mess opting for the race to the top newest standards ... that always works so well and ensures the user base is always upgrading.
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.
To be clear, ADE’s behaviour is not conforming to any version of the standards it claims to implement. If it had been, it would reject that specific max-width property declaration as having an invalid value and ignore it, not reject the entire document: every single version of CSS has required that forwards-compatible behaviour.
PDF is not somehow immune to this either — a non-conforming implementation could similarly break what are meant to be forward-compatible extension points by raising an error on an unknown stream or object instead of (as required by the standard) ignoring it.
So if I understand correctly a struggling epub viewer or ADE should skip css that it considers malformed - which means the reason my viewers have considered a epub to be not able to be viewed / corrupt / whatever it is for some other reason than more recent / current css implementation.
PDFs certainly can suck, more often those that will only work with abode's software and other viewers I've tried can not.
While plausible, I would suspect it’s more likely you’ve just run into bugs than forwards-compatible error behaviour — most ePubs don’t get anywhere near actually interesting CSS!
An epub is just a plain html webpage compressed into a zip and its extension changed from .zip to ".epub". Assuming you have a web browser, you have something that will almost certainly render your epubs contents.
PDF is not nearly as pleasant under the hood. It's down right lovecraftian.
The lovecraftian horror of pdf mostly comes into play through the sheer amount of software that supply almost correct pdf. It's not enough to be able to read pdf anymore, you also have to be able to deal with software that emits subtly wrong documents.
That's part of it, but the design of PDF really doesn't help
Adobe really have perfected act of making the most shoddy software that is still possible to sell
I'm reminded of "PSD is not my favourite file format."
https://b3n.org/psd-is-not-my-favourite-file-format/
or in the code:
https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m
I'm aware thanks. Mostly it's just my preferred viewer is older than css4 but it's been nice to find out why that was the case.
PDFs can be painful as well, more often it's then using abode's pdf viewer, but it's far less common for me. There was a time many years ago when I understood PDF structures better, back when I chose to manually edit and fix a couple of malformed PDFs.
I was floored to discover this recently when I clicked "edit" in calibre for the first time a few weeks ago.
Straight HTML, edit anything everywhere. Super slick.
I think its one reason ive been happy with software based epub readers where upgrading is usually reasonable to do. Either on my phone or android based eink reader. That said if they change too much then yea nobody will produce the new standard and only support the old one if it isnt carefully designed for graceful degredation.
>but it can’t validate CSS against a renderer which is fundamentally broken!
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.
You are of course correct that ePub nowadays doesn’t mandate a given version of CSS (though earlier versions did!), but that doesn’t matter in this case: it’s non-conforming according to even CSS level 1 (1996), per https://www.w3.org/TR/REC-CSS1-961217#forward-compatible-par...
> illegal values, or values with illegal parts, are treated as if the declaration weren't there at all
So a conforming implementation would ignore that max-width property declaration, not raise an error.
And those earlier versions of ePub which defined a required subset of given CSS standards? The forwards-compatible parsing rules were part of their subset.
No, the CSS spec is specifically designed to be forwards compatible because of exactly this issue. Any invalid CSS rule should only cause that specific line to be ignored, not the whole stylesheet. And certainly even if your CSS parser chokes in some specific case, it shouldn't cause your ereader to fail to load the entire book!
The parser is broken. The CSS standard says that parsers MUST ignore properties they don't recognize.
ePub3 is CSS2.1 (+ some extras) CSS21 standard says "Illegal values. User agents must ignore a declaration with an illegal value."
Ignore != Fatal error
If the renderer completely fails because of a minor issue when parsing the css, that is broken.
I don't like .epub. I understand the reasons why this format exists, and I am 100% behind those reasons. But it's because I don't find any EPUB readers appealing to me. Just give me a FoxIt Reader clone for .epub, that's all. But naaaah!!, every single fucking e-pub reader that I tried must be a fucking library collector instead, like it's 2000's Windows Media Player style. I hate that.
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.
Have you tried foliate? Their embedded reader works quite well for me.
Hmm, Sumatra PDF perhaps?
As someone who loves FoxIt reader, I'm building https://merrilin.ai to be the best damned ebook reader out there, to support PDF and epub. FoxIt's annotation system is one of the best I've experienced and I want to design one that is just as good if not better.
Building a robust annotation system for both PDF and EPUB is a tough technical challenge, but definitely needed. I've been working in a similar space and recently open-sourced it. It's a local-first 3D library for organizing and reading EPUBs and PDFs directly in the browser. It's called KoreShelf on Github
Wow. This brings up some (bad) memories of working with an .epub export about 10 years ago. We had some embedded fonts to work around some poor rendering in some of the readers we tested, but some of the readers ignored the fonts altogether, causing the content to render boxes (bangs head on table)
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)
bro, what an anchor to the past that framework is