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.
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.
> 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.
You're not the user here. Average joes are. You're in the 0.001%. Your asks are arcane and orthogonal to most users of software, who just want their PC to do something neat and useful.
These issues you bring up are also entirely technically solvable. If we threw Flash out because of these misgivings (read: it was that Jobs didn't want to allow runtimes on his platform), then we truly destroyed some of the most valuable tech on the planet to satisfy "standards" boffins. What a waste.
> You're in the 0.001%. Your asks are arcane and orthogonal to most users of software, who just want their PC to do something neat and useful.
Right up until enshittification kicks in and suddenly everyone cares and there are shouts of destroying the evil techbros who are poisoning the minds of our youth to buy a new yacht.
Can you imagine the situation if Jobs hadn't killed Flash? Most of the commercial websites required a Flash blob to deliver full functionality even back then in the early 2000's. Adobe never even vaguely pretended to be the good guys, they would have enshittified as soon as they possibly could, as hard as they possibly could (as they have done with the rest of their software). The entire web would be held to ransom at this point.
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.
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.
> 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)?
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.
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 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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
> 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.
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.
"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...
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.
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.
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.
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.
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.
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.
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.
>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!
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.
> 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
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.
> Having to install a binary blob
It was already installed for you.
> 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.
You're not the user here. Average joes are. You're in the 0.001%. Your asks are arcane and orthogonal to most users of software, who just want their PC to do something neat and useful.
These issues you bring up are also entirely technically solvable. If we threw Flash out because of these misgivings (read: it was that Jobs didn't want to allow runtimes on his platform), then we truly destroyed some of the most valuable tech on the planet to satisfy "standards" boffins. What a waste.
> You're in the 0.001%. Your asks are arcane and orthogonal to most users of software, who just want their PC to do something neat and useful.
Right up until enshittification kicks in and suddenly everyone cares and there are shouts of destroying the evil techbros who are poisoning the minds of our youth to buy a new yacht.
Can you imagine the situation if Jobs hadn't killed Flash? Most of the commercial websites required a Flash blob to deliver full functionality even back then in the early 2000's. Adobe never even vaguely pretended to be the good guys, they would have enshittified as soon as they possibly could, as hard as they possibly could (as they have done with the rest of their software). The entire web would be held to ransom at this point.
I was an average-joe high school student back then.
People hated flash. Even non techies.
Sure, but Adobe was never going to solve them.
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.
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.
> 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)?
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.
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.
There was more unique content/UI in the Flash era.
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.)
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.
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.
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.
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.
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.
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.
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
> 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.
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.
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.
Adobe Digital Editions and RMSDK were recently sold to Wipro Engineering: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
Sold or outsourced?
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
Have you tried the beta? Have you found it to be substantially better?
> 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
Is there a way to root the kobo and put a modern renderer in place?
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.
"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...
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.
Death to Adobe. For this reason and 10,000 others.
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.
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.
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.
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.
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.
It's always CSS.
compatible style stuff
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.
Hmm, Sumatra PDF perhaps?
>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.
bro, what an anchor to the past that framework is
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)
BOOX works fine. One solution is to ask Codex to reformat your epub file before importing it to your ereader.