Wha'happen with ePUB4? Anybody know?

[Hitch]

Hey, lads and lassies (all two of you....):

Does anybody here have insight into what the Hades happened with ePUB4? Has that just died a sad, tired death from disinterest? It seems to me that there was activity in '18 and '19 and then...zip.

Sure, we had Covid, but that would have, one might have thought, been a good time to work on it from home and all that. Has it gone the way of the Dodo?

Anybody know anything at all? Surmises and wild speculation also welcome. :-)

Hitch

[jhowell]

I do not know of any ongoing effort toward producing an EPUB 4 specification. I saw mention of it as a possibility a few years ago but nothing recently. I believe that the slow adoption of EPUB 3 and the lack of interest by publishers and book stores has killed the idea of developing a major change to EPUB for now.

EPUB 3.3 is in development and on track to become the next version of the EPUB specification. It is an incremental change to the current EPUB 3.2 spec. The latest working draft was released on February 11, 2022. There is also ongoing work on the EPUBCheck tool to test conformance of EPUB 3.3.

[KevinH]

And epub 3 finally took off especially in Japan and internationally. That alleviated part of the need for an epub 4, especially from the newly adopted epub3 publishers. Plus the potential to lose the large installed base of epub users whose devices would not support it.

All in all, the epub4 spec as written was clearly a product of a committee well removed from actual coding and tool chains used in publishing. A lot of existing tools in e-publishing rely in part or full on the strict syntax of xhtml/xml (i.e, almost all regular expressions based parsing do for example) and would need to be completely rewritten to allow for the more spaghetti-like rules of html, free floating '<'s, node injection rules, etc, that a real html parser must account for (take a peak at the html whatwg spec to see the complexity required by a real html parser.)

I personally am much happier with the slower evolution of the epub 3.x spec, and the intelligent deprecation of epub3's more esoteric features not easily supported in browsers such as trigger, switch, refines of refines, the substitution of epub:type with existing aria-role attributes.

Evolving the spec by slight changes and warnings in new releases of epubcheck, is much better approach for the e-publishing industry.

[Hitch]

Originally Posted by KevinH

And epub 3 finally took off especially in Japan and internationally. That alleviated part of the need for an epub 4, especially from the newly adopted epub3 publishers. Plus the potential to lose the large installed base of epub users whose devices would not support it.

All in all, the epub4 spec as written was clearly a product of a committee well removed from actual coding and tool chains used in publishing. A lot of existing tools in e-publishing rely in part or full on the strict syntax of xhtml/xml (i.e, almost all regular expressions based parsing do for example) and would need to be completely rewritten to allow for the more spaghetti-like rules of html, free floating '<'s, node injection rules, etc, that a real html parser must account for (take a peak at the html whatwg spec to see the complexity required by a real html parser.)

I personally am much happier with the slower evolution of the epub 3.x spec, and the intelligent deprecation of epub3's more esoteric features not easily supported in browsers such as trigger, switch, refines of refines, etc.

Evolving the spec by slight changes and warnings in new releases of epubcheck, is much better approach for a slower moving e-publishing industry.

I'm far, far happier with the idea of ePUB3 being developed. (I've been cranky about the origination of ePUB3.x, and all that. Felt half-assed and all Apple, all the time....)

During our morning production meeting, ePUB4.x had come up. We had a customer inquiring thereafter, for whatever godforsaken reason and I realized it had flown right out of my head. That's why I thought I'd ask here--you guys would know, if anybody would.

Thanks, Kev, @jhowell.

Hitch

[Quoth]

The epub3 is a minority of real ebooks and multimedia is better served by iOS & Android apps.

IMO they added the wrong things to epub3, they concentrated too much on interactive, video, animation and audio instead of simply having a better ebook experience. The only HTML "interactive" thing I'd have added was the ancient Client side pure HTML image map so tap/select/click on a different region of one image jumps to a link (page).
The existence of the non-DRM features in KFX and kepub rendering shows too what epub2 source can provide.

EReaders have a very long life. Epub 4 as a format for actual ereaders rather than iOS & Android apps with epub4 is doomed. Actual ereader support for complete epub3 in any fashion compared to Apps with epub3 is poor. Many apps support little of epub3.

Seems to me that after epub2 they lost sight of ebooks and were seduced by HTML5 and trying to be an alternative to multimedia app frameworks for iOS and Android.

I know the epub3 Evangelists have a completely different view, but I purely considering people wanting to read a novel on eink. Most screens are hardly big enough for science textbooks. Video, colour and audio needs an OLED or LCD iOS or Android tablet anyway.

[KevinH]

We have had this argument before. Epub3 is the leading format in Japan, and in countries with rtl, and vertical languages, is much better for accessibility in many ways and allowing synchronized reading of audio with text, and of course a broad range of video. Epub3 can be converted to Kindle formats as well. Is supported by Readium SDK, the Thorium Reader, ADE 3, iBooks, etc.

Epub2 is basically dead outside the US and a few other places stuck with slow and old devices. Good riddance.

[salamanderjuice]

Originally Posted by Quoth

The epub3 is a minority of real ebooks and multimedia is better served by iOS & Android apps.

IMO they added the wrong things to epub3, they concentrated too much on interactive, video, animation and audio instead of simply having a better ebook experience. The only HTML "interactive" thing I'd have added was the ancient Client side pure HTML image map so tap/select/click on a different region of one image jumps to a link (page).
The existence of the non-DRM features in KFX and kepub rendering shows too what epub2 source can provide.

EReaders have a very long life. Epub 4 as a format for actual ereaders rather than iOS & Android apps with epub4 is doomed. Actual ereader support for complete epub3 in any fashion compared to Apps with epub3 is poor. Many apps support little of epub3.

Seems to me that after epub2 they lost sight of ebooks and were seduced by HTML5 and trying to be an alternative to multimedia app frameworks for iOS and Android.

I know the epub3 Evangelists have a completely different view, but I purely considering people wanting to read a novel on eink. Most screens are hardly big enough for science textbooks. Video, colour and audio needs an OLED or LCD iOS or Android tablet anyway.

Multimedia is a mistake but ePub 3 is more than just multimedia. Some languages just don't work well or at all with ePub 2 due to lack of vertical writing and right to left support. Plus the addition of MathML for science/math textbooks. If you can actually reflow and resize a math/science textbook there's no reason it can't work on a 6" screen but with many titles still shipping horrid versions that use images for equations for kindles/ancient readers that are almost always blurry AND the wrong size to surrounding text often considerably so. This is especially bad after being used to crispy gorgeous TeX-made PDFs.

[Quoth]

Some languages just don't work well or at all with ePub 2 due to lack of vertical writing and right to left support. Plus the addition of MathML for science/math textbooks.

Yes, ebooks especially KF7 were too US Centric. A solved problem 10 years before anyone made an eink reader.
The language support, decent LTR, RTL and vertical in one page.

I agree in theory many science textbooks should be possible, but some would be challenging on 6", even 300 dpi, never mind the old 800 x 600 or 167dpi screens.

All of that (bidi, asian, mathml) should have been in epub2. Absolutely short sighted it wasn't. I'd seen DOS text mode do bidi in 1980s.

Problem is as a publisher how do I know how many physical ereaders support mathml, Bidi and vertical? So we stick to epub2 for fiction and PDFs, ideally paper, for stuff that doesn't work on epub2. We test on real physical ereaders.

[salamanderjuice]

Originally Posted by Quoth

Yes, ebooks especially KF7 were too US Centric. A solved problem 10 years before anyone made an eink reader.
The language support, decent LTR, RTL and vertical in one page.

I agree in theory many science textbooks should be possible, but some would be challenging on 6", even 300 dpi, never mind the old 800 x 600 or 167dpi screens.

All of that (bidi, asian, mathml) should have been in epub2. Absolutely short sighted it wasn't. I'd seen DOS text mode do bidi in 1980s.

Problem is as a publisher how do I know how many physical ereaders support mathml, Bidi and vertical? So we stick to epub2 for fiction and PDFs, ideally paper, for stuff that doesn't work on epub2. We test on real physical ereaders.

Pretty much every textbook should work, even at 167dpi. Most monitors and laptop screens are far below 167dpi even a 4K 27" monitor is only 163ppi. Text looks better at higher dpi/ppi but it's perfectly tolerable to read math equations on a 90ppi monitor unless they're miniscule. But you have to have the text properly rendered and not png or jpegs at whatever size the publisher decided.

If you look at Kobo's site it's pretty clear even for English novels EPUB 3 is taking or has taken over. They tell you at the bottom of the page whether a book is EPUB 2 or 3.

[rantanplan]

IIRC, Penguin Random House only serves epub3 for some time now.

[Quoth]

Originally Posted by rantanplan

IIRC, Penguin Random House only serves epub3 for some time now.

But all my Random Penguins have been bought at Amazon, downloaded azw3 to PC & converted to epub2. Also they are clueless. Big doesn't mean smart.

Amazon has 92% of English Language ebook market.

Gutenberg is the biggest PD source and is epub2.

How do I even know which ereaders can display an epub3 and which epub3 features are supported? So we won't be producing any epub3. The epub2 books work on any epub ereader or app and are what is uploaded to Amazon KDP.

[Quoth]

Originally Posted by salamanderjuice

Pretty much every textbook should work, even at 167dpi. Most monitors and laptop screens are far below 167dpi even a 4K 27" monitor is only 163ppi. Text looks better at higher dpi/ppi but it's perfectly tolerable to read math equations on a 90ppi monitor unless they're miniscule. But you have to have the text properly rendered and not png or jpegs at whatever size the publisher decided.

It's true about a 120 dpi screen being fine, but the size in pixels is maybe at worst 1280 x 720, typically 1920 x 1080. Or older 4:3 screens may have 1024 x768 or 1600 x 1200. The basic 6" 167 dpi ereaders are only 600 x 800. A 2K 23" screen isn't very high DPI but it's 2560 x 1440 pixels.
So an older 6" 167 dpi screen is more challenging than a cheap laptop. Even the 6" @ 300 dpi is problematic for some diagrams, equations and tables. I'd say a 7.8" or 8" at 167dpi to 300 dpi is a minimum. The DX and later screen upgrade DXG are slow and only 167 dpi, but they are 9.7"; a table or diagram on them works far better than a 6" 300 dpi screen.

Above 120 dpi the screen size is more important than dpi, though I certainly prefer 300 dpi. A fax is Letter size or A4, or even Legal size. They are 100 dpi or 200 dpi, with no shades, only black or white. The oldest eink has 4 shades and later black, white and 14 shades. If the greys are utilised in antialiasing then you've about two to three times the effective resolution compared to fax, but crippled by a 6" screen.

[salamanderjuice]

Originally Posted by Quoth

But all my Random Penguins have been bought at Amazon, downloaded azw3 to PC & converted to epub2. Also they are clueless. Big doesn't mean smart.

Amazon has 92% of English Language ebook market.

Gutenberg is the biggest PD source and is epub2.

How do I even know which ereaders can display an epub3 and which epub3 features are supported? So we won't be producing any epub3. The epub2 books work on any epub ereader or app and are what is uploaded to Amazon KDP.

What you convert your Amazon proprietary formats to is irrelevant. I convert my AZW3 to ePub 3 because its typically in Japanese and is broken any other way. Amazon also controls 0% of the ePub sales market. They will also convert an ePub 3 to their junk for you too.

Kobo's back to the touch at least will support ePub 3 or at least a subset and those are almost a decade old at this point. Pocketbooks will do it and so can Oynx devices. No, not every feature is supported but a good chunk is. So besides ancient Sony readers and the like I think it's more supported than you think.

[Quoth]

But what subset?
It's impossible for us to easily know, so we won't use it.

[Hitch]

Y'know, I should have remembered not to inadvertently start this argument.

Many of us, me included, didn't go wild for multimedia, but let's be fair, ePUB3 does have a lot of other functionality. I am glad of that functionality, particularly for reading direction, etc. I would love it if ePUB3 would mature. Would be loverly, to coin a phrase. :-)

Hitch