
ePub 3.2 - rahuldottech
https://www.w3.org/publishing/epub32/epub-spec.html
======
reagent_finder
I feel like there's a slight lack of grassroots activity with epubs, people
tend to work with mature products or random e-readers. I've recently
experimented a bit with making epubs by hand (bash+perl) and they tend to
break readers more often than not.

So I feel we've come to the spot where there's standards, but then there's
convention over (a) decade(s) that just trumps standards. Reminds me of DHCP
where I've yet to come across three implementations that agree on certain
aspects. Also, is 'supports epub x.y' been a selling point in any reader so
far?

I'm looking through the changes and holy hell, this makes me feel like
punching an engineer, and I am one! Everything is buried under three or more
layers, requiring at least 3 clicks and a bunch of scrolling and usually just
refers to what they've changed compared to the PREVIOUS version. While fine
for a standard, this is absolutely awful for anyone who doesn't work with epub
files daily (which I'm guessing is a very small minority).

If you're interested in changes written for humans, this link is what you're
looking for: [https://www.w3.org/publishing/epub32/epub-
overview.html](https://www.w3.org/publishing/epub32/epub-overview.html) It
doesn't contain motivation for these changes, though, so we'll go with "some
engineer thought these would be a good idea"

I guess I'd like to ask the working group:

#1 How widespread would you consider high/recent version support for epubs to
be?

#2 How would you sell epub 3.2 support to people developing e-readers or
reader applications?

#3 Why isn't the first page filled with "Hey guv, you're an engineer who's
interested, here's what epub is and does, and here's a link with all the
recent changes along with update motivation information" because looking at
this site, I could not find a single thing for convincing manager/C-level
types to grant 200 product update hours for this.

~~~
m-p-3
> I've recently experimented a bit with making epubs by hand (bash+perl) and
> they tend to break readers more often than not.

Me too, and I wish SVG support was better on most eReader (not a good
experience so far), and that there was official support for MathML or
something equivalent. It hurts to see so many books using raster pictures to
display a formula or a diagram, when it would look crisper and flow better if
it was vector-based.

~~~
Finnucane
I'm in academic book publishing, and our books have a lot of charts and
diagrams that are challenging to display on certain readers that have poor SVG
support. Also, tables can easily be larger than the readers can comfortably
handle, and certain readers (yeah, looking at you, Kindle) suck at it.

You'd think there would not be such a great difficulty in this, since epubs
are constructed out of the same basic tech stack as web pages.

I think the fundamental problem is that Amazon, Apple, etc., don't have much
incentive to support texts beyond the most commercial genres.

------
Tepix
I feel like EPUB is a standard who's features are underutilized. Is there a
nice high-level overview of EPUBs capabilities?

I found a German text from 2018 that covers EPUB 3.0-3.2 (which was obviously
still a draft back then): [https://www.dpc-
consulting.org/epub-3-3-0-1-3-1-3-2-das-vers...](https://www.dpc-
consulting.org/epub-3-3-0-1-3-1-3-2-das-versions-chaos-der-ebook-formate/)

It links to a long blog post that covers recent EPUB development by Dave
Cramer, co-chair of the W3C Community Group: [http://epubsecrets.com/why-
specs-change-epub-3-2-and-the-evo...](http://epubsecrets.com/why-specs-change-
epub-3-2-and-the-evolution-of-the-ebook-ecosystem.php)

EPUBCheck is an open source tool that can check your EPUB files against the
EPUB 3.2 spec.
[https://github.com/w3c/epubcheck](https://github.com/w3c/epubcheck)

~~~
shakna
The features are underutilised because most readers simply don't support them.

There's no point using a feature if it'll just break the book for the vast
majority of your audience, and it doesn't look like that situation is going to
change anytime soon.

------
foo_in_bar
It's such a nice standard, I just wish it had better support on E-readers
(looking at you Kindle).

~~~
robin_reala
Well, it’s only Kindle that insists on a proprietary format. Everyone else
does ePub 2 fine (ePub 3 support is spotty).

~~~
Mediterraneo10
Kindles can read .mobi files, which is a pretty open format. Calibre can
easily convert EPUBs to .mobi (or to the similar .azw3 format) for reading on
Kindle. While Amazon has introduced recently a new format with advanced
typographic features that is highly proprietary (.kfx), uptake of it among
publishers has been slow.

~~~
robin_reala
Mobipocket has been dead for the last couple of years and I can’t find a spec
anyway. The Library of Congress describe it as a “proprietary, partially
documented, binary format for ebooks”[1] which doesn’t really meet “open” by
my definition. As for KFX, that’s 100% proprietary, yes.

Amazon in the US at least has sewn up the ebook market such that they have no
interest at least in implementing open standards. The best thing to do in
these situations is to vote with your wallet.

[1]
[https://www.loc.gov/preservation/digital/formats/fdd/fdd0004...](https://www.loc.gov/preservation/digital/formats/fdd/fdd000472.shtml)

------
patrickg
Changelog to 3.0.1 here: [https://www.w3.org/publishing/epub32/epub-
changes.html](https://www.w3.org/publishing/epub32/epub-changes.html)

------
fouc
I wish MacOS had a good ePub reader that did not insist on multiple column
view and runs as a standalone app.

Kind of sad XULRunner got killed or I could run EpubReader as a stand alone
app.

~~~
robin_reala
Apple Books? Switching it to single page view is pretty trivial.

~~~
fouc
iBooks app? You have to fiddle with the size of the window and once you get
one column, it ends up with ridiculously huge margins on it.

~~~
robin_reala
It was renamed to Books in Mojave. Either way, you can just select View /
Single page from the menu and it resizes to a single column view with normal
margins. That isn’t supported in full screen view tbf.

~~~
fouc
Yeah I prefer a single column while keeping the window at the full width of
the display. It tends to shrink the window to fit it's preconceived notions of
"vertical rhythm" as they call it in the text world I guess - or usually
trying to keep the width to 70-80 characters. I don't like this though

