Overview of features supported by ebook readers?

[hobnail]

Originally Posted by KevinH

Recommending EPUB2 over EPUB3 just to support old dedicated e-readers that are rapidly dying out is probably not a good choice when new devices and apps support both.

Especially when the book isn't using any of those "fancy" unlikely-to-be-supported epub3 only features.

[Quoth]

Originally Posted by JSWolf

But once the ePub eBook is created, it makes a much better source format then the word processing file.

No, it's only for distribution or further conversion. No-one is going to use an epub editor to edit/revise/write a book or reformat to create a PDF proof for paper publishing. It's as mad as suggesting a PDF is a source format. An epub is a destination format.

[fbrzvnrnd]

Originally Posted by Quoth

No, it's only for distribution or further conversion. No-one is going to use an epub editor to edit/revise/write a book or reformat to create a PDF proof for paper publishing. It's as mad as suggesting a PDF is a source format. An epub is a destination format.

My source format is XHTML. And I build PDF and ePub from XHTML. Many publishing houses uses XML as source format.

[Quoth]

No, NO-ONE sensibly uses XHTML or XML as a source format to write books. They are an intermediate format for formatting. You MIGHT create very short documents in them.

And no publishing house uses XML as source format for books. They might have XML in the workflow. Fiction is via wordprocessor -> PDF proof.
Non-fiction is potentially more complicated if formulas etc involved.

We obviously have a completely different view of content creation and editing work flows.

[fbrzvnrnd]

Originally Posted by Quoth

No, NO-ONE sensibly uses XHTML or XML as a source format to write books. They are an intermediate format for formatting. You MIGHT create very short documents in them.

And no publishing house uses XML as source format for books. They might have XML in the workflow. Fiction is via wordprocessor -> PDF proof.
Non-fiction is potentially more complicated if formulas etc involved.

We obviously have a completely different view of content creation and editing work flows.

Perhaps you are considering your way to work as the only one. I published hundred of books using XML as source format and today - for example - I'm working on XML for one of bigger publishing house in Italy. "Source" obviously is not the author manuscript, but the document core a publishing house uses to create the destination formats. XML is one of the best core for workflow to conserve and produce different product, as web-app, ePub, PDF and more.
And no, you can work on large project directly in XML, if you are able to do this. My last poetry ebook was coded directly in XML and javascript. Don't look at your garden as if it were the world. The world is bigger.

f.

[Notjohn]

Doesn't Amazon recommend epub2 for Kindle editions? That's my understanding, and given that Amazon is now deprecating "mobi" uploads, I assume every semi-professional who distributes through the KDP platform will be building epub2s only. Am I missing something?

(I appreciate that some or many people reformat books they only mean to read, but I couldn't be bothered to do that. I just read what's sent to me, whether it be galleys, ARC, epub, PDF, or even Word doc. I'm speaking here only as a publisher of print and digital books, not as a consumer of them.)

[Quoth]

"Source" obviously is not the author manuscript,

No, the author's manuscript is ABSOLUTELY the source. The XML is an intermediate format.

[fbrzvnrnd]

Originally Posted by Quoth

No, the author's manuscript is ABSOLUTELY the source. The XML is an intermediate format.

I *NEVER* published an author's manuscript. The author's manuscript is a manuscript, not a final work. I'm a publisher, not a "printer". The source of an ebook is the XML I work with the author, not his manuscript. The manuscript I receive from an author and the ebook I publish are not the same thing, in the middle there is the publisher work: editing, corrections, iconographic material, interactive material, analytical indexes, thematic paths, sources, requests for rewriting or new drafts... and counting. This is the *source*, not the author draft. But I think we have a completely different idea of ​​what a publisher needs to do professionally.

[Jellby]

Rather than source call it "archival" format. Something you can happily save, knowing that it will be relatively easy in the future to modify, convert to other formats, update, etc.

[Quoth]

This is a stupid argument. You are confusing content creation with a production process.

The whole point of XML is transfer of content between different systems. It might be used as the file format for some content creation programmes. But anyone actually editing XML with a text editor create or edit original content is mad.

I know of no writers or editors that would do that. Please don't confuse how you do production with how people create and edit content. It's a bigger world than your work flow.

[KevinH]

Straight from the most recent Kindle Publishing guidelines:

To ensure your HTML or XHTML documents are well formatted for accessibility, we recommend they adhere to the following document accessibility standards:

The W3C Web Content Accessibility Guidelines
The International Digital Publishing Forum’s EPUB 3 Accessibility Standards

The only way to get EPUB3 Accessibility Standards is via EPUB 3.

That is what I have been saying since the beginning. Amazon would rather have an EPUB3 with full Accessibility and Semantic markup than an epub2.

So recommending people submit and keep epub2 versions is and has been outdated for some time!

Originally Posted by Notjohn

Doesn't Amazon recommend epub2 for Kindle editions? That's my understanding, and given that Amazon is now deprecating "mobi" uploads, I assume every semi-professional who distributes through the KDP platform will be building epub2s only. Am I missing something?

(I appreciate that some or many people reformat books they only mean to read, but I couldn't be bothered to do that. I just read what's sent to me, whether it be galleys, ARC, epub, PDF, or even Word doc. I'm speaking here only as a publisher of print and digital books, not as a consumer of them.)

[fbrzvnrnd]

Originally Posted by Jellby

Rather than source call it "archival" format. Something you can happily save, knowing that it will be relatively easy in the future to modify, convert to other formats, update, etc.

It's ok. But the author's manuscript is not a source. It is one of the elements that contribute to the creation of the book. The source is always born during the editorial work. Unless you just print self-publishing stuff.

[fbrzvnrnd]

Originally Posted by Quoth

This is a stupid argument. You are confusing content creation with a production process.

Well, no. As I wrote before you are confusing the author draft with the content creation. And - in digital books - you are creating text in XML.

The whole point of XML is transfer of content between different systems. It might be used as the file format for some content creation programmes. But anyone actually editing XML with a text editor create or edit original content is mad.

All the publishing houses that conserved source in XML had no problem to convert quickly their books to ePub, some years ago. All the publishing houses that only had "word processor manuscript" or obsolete DTP files as source, had to send tons of paper books in India to ocr scan.

I know of no writers or editors that would do that.

Maybe this is your problem.

Please don't confuse how you do production with how people create and edit content. It's a bigger world than your work flow.

As I wrote, in those days I'm working, as service, for a big publishing house in Italy for editing and correction of digital content. In docbook.

f.

[hobnail]

Originally Posted by Quoth

This is a stupid argument. You are confusing content creation with a production process.


But anyone actually editing XML with a text editor create or edit original content is mad.

Back when I wrote handouts and whatnot for classes I taught I wrote all of it in a markup language, LaTeX. Its syntax is similar to xml. I've never liked using wysiswyg because it's too easy to lose (waste) time fussing with the appearance instead of focusing on the content. If I were writing today I'd be using sigil and working in the window that has the html.

[Tex2002ans]

Originally Posted by what

Is there some overview like https://caniuse.com/ that shows which ebook reader supports which formats and features?

Yes, although not as good/thorough:

http://epubtest.org/

Although it looks like the old info/tests haven't been converted over to the redesigned site.

From ~2014-2018 they tested lots of different apps/devices.

For example, I wrote about WOFF in "Font Best Practices".

You could still use Archive.org to crawl through the old site:

• Archive.org of epubtest.org
• EPUB3 > Features > WOFF

But, for the most part, KISS (Keep It Simple Stupid). Too many of the fancy things would break across readers.

If you know you're only focused on selling in a single store (like Apple iBooks), you might be able to get away with a bit more...

But trying to sell an ebook wide, stick with the lowest common denominator. Like scene breaks with simple centered asterisks, not CSS3 ::after.

Originally Posted by Quoth

No, NO-ONE sensibly uses XHTML or XML as a source format to write books. They are an intermediate format for formatting. You MIGHT create very short documents in them.

And no publishing house uses XML as source format for books. They might have XML in the workflow. Fiction is via wordprocessor -> PDF proof.
Non-fiction is potentially more complicated if formulas etc involved.

You must've missed the 2019 thread:

"Workflow for simultaneous EPUB and PDF production?"

You may also be interested in this talk given at ebookcraft 2018: "HTML-First at Wiley, or, How We Learned to Stop Worrying and Love the DOM".

There's also JATS, which is XML mostly used in journals.