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.
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.
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.
> 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).
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.
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.
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.
>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 subset of CSS? 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 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.
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 the max-width property as having an invalid value, and ignore that property declaration.
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.
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.
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)
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.
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.
I used EPublish for my first novel, Means and Motive, just published here, DRM-free: https://www.amazon.com/dp/B0GYCZJVGX
So far I haven't heard of compatibility issues, so I think EPublish has hit the sweet spot of EPUB targeting. I agree, however, that it feels like the old days of targeting IE6 on the web. Old readers still exist out there, so we have to aim for the lowest common denominator.
I 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.
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).
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
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.
> 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 subset of CSS? The forwards-compatible parsing rules were part of their subset.
Ignore != Fatal error
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.
PDF is not nearly as pleasant under the hood. It's down right lovecraftian.
https://b3n.org/psd-is-not-my-favourite-file-format/
or in the code:
https://github.com/gco/xee/blob/master/XeePhotoshopLoader.m
Straight HTML, edit anything everywhere. Super slick.
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.
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)