Why ePub 3?

[KevinH]

As it stands much of "epub 3.1" dc metadata will actually be closer to what epub2 dc metadata was. The big change will be in non-dc metadata where epub 3.1 would require no old fashioned (self closing) epub2 meta statements. The key things done in the old meta data can easily be done in the new style meta (and without refines) but things like cover image setting will be replaced by manifest properties.

[nabsltd]

Originally Posted by DiapDealer

The answer is "all of them". Epub3 engines render Epub3s using epub3 specifications.

I would be shocked if the underlying HTML/CSS renderer for a reader that understands EPUB3 changes when the reader encounters an EPUB2.

Basically, the reason that readers that understand EPUB3 render better is not because of the EPUB3 part...it's because the HTML/CSS renderer has been upgraded along with the EPUB unpacker. There are many EPUB2-only readers that handle a lot more HTML/CSS than is actually legal in the EPUB2 specification. In the same way, a reader that understands EPUB3 will likely handle more HTML/CSS than is required by the EPUB3 spec, simply because the HTML/CSS renderer is newer.

[DiapDealer]

Originally Posted by nabsltd

I would be shocked if the underlying HTML/CSS renderer for a reader that understands EPUB3 changes when the reader encounters an EPUB2.

You shouldn't be shocked at all. Bookari uses Readium for its EPUB3 rendering engine and RMSDK for EPUB2. Many dedicated devices also use entirely different engines for rendering the different formats they make available via their walled gardens. Do you think Kobo's kepubs are rendered with the same engine they use for presenting their regular epubs?

In all honesty, I would be more shocked if a reading system that supports EPUB3 didn't use an entirely different rendering engine than it does for its EPUB2 content.

[AnotherCat]

Originally Posted by nabsltd

...Basically, the reason that readers that understand EPUB3 render better is not because of the EPUB3 part...it's because the HTML/CSS renderer has been upgraded along with the EPUB unpacker. There are many EPUB2-only readers that handle a lot more HTML/CSS than is actually legal in the EPUB2 specification. In the same way, a reader that understands EPUB3 will likely handle more HTML/CSS than is required by the EPUB3 spec, simply because the HTML/CSS renderer is newer.

Thanks, that answers my earlier question in a lucid and non emotional manner (and is aligned with what I would have expected).

[nabsltd]

Originally Posted by DiapDealer

You shouldn't be shocked at all. Bookari uses Readium for its EPUB3 rendering engine and RMSDK for EPUB2.

Although this may be, it makes no sense.

After the determination of whether a file is EPUB2 or EPUB3, the metadata read gets done, and the structure of the book sorted out by the program. At that point, it should then pass the first HTML page to the HTML/CSS renderer, and having different ones is merely code bloat. There is nothing in the HTML of an EPUB2 that will render incorrectly using an HTML/CSS renderer that is EPUB3-compliant.

Do you think Kobo's kepubs are rendered with the same engine they use for presenting their regular epubs?

I've never seen the HTML inside a kepub, but based on the MR Wiki description, again, using another HTML renderer is just useless code bloat. The kepub reader and epub reader could use the same HTML/CSS rendering engine. The extra kepub features are merely for navigation and annotations, and the next level above the renderer should pay attention to them. Also, there is zero need for the extra HTML to allow the reader app to offer those same features...most of them are available on EPUB on Kobo readers, too.

Basically, this is another case of a company that builds decent hardware but can't write good code.

[AnotherCat]

Originally Posted by salamanderjuice

Yea, and epub 3 has plenty of features that are useful to a lot of users too just like .docx. Fixed layouts, more language support, more accessibility support, video & sound, MathML,better metadata etc.

Most Word documents could be written in .doc format too. I mean why not use .doc? Then I can open it on my Pentium laptop running Word 97 right?

Thanks for the response but it would seem that in your run away defensive enthusiasm you have lost track of the original question which was along the lines of why use epub3 in cases where epub2 meets the need.

It does not seem to me that there is any claim in that or subsequently that epub3 should not be used when it delivers benefits for cases when the media profits from its use or when the producer of the media otherwise desires for whatever reason whether useful or not.

So, your response tells me nothing. Thanks for trying though.

[JSWolf]

Originally Posted by nabsltd

I've never seen the HTML inside a kepub, but based on the MR Wiki description, again, using another HTML renderer is just useless code bloat. The kepub reader and epub reader could use the same HTML/CSS rendering engine. The extra kepub features are merely for navigation and annotations, and the next level above the renderer should pay attention to them. Also, there is zero need for the extra HTML to allow the reader app to offer those same features...most of them are available on EPUB on Kobo readers, too.

Basically, this is another case of a company that builds decent hardware but can't write good code.

The code that handles ePub 2 also handles the DRM. If Kobo went with the newest version of RMDSK, then maybe they could do away with Access (the renderer for kepub/ePub 3). But then they'd lose kepub.

[AlexBell]

Let me step sideways or perhaps go off topic.

If I continue to produce ePub2 ebooks for the MR library will they be readable in ePub3 readers? Are there any ePub3 only readers?

If I want to learn how to produce ePub3 ebooks where can I go to learn how to do it?

[Doitsu]

Originally Posted by AlexBell

If I continue to produce ePub2 ebooks for the MR library will they be readable in ePub3 readers?

AFAIK, epub3 apps are supposed to also support epub2 books, and I haven't encountered an epub3 app that wouldn't read epub2 books.
Some epub apps, e.g. ADE 4.5/RMSDK 11.5 will actually use different rendering engines for epub2 and epub3 books.

Originally Posted by AlexBell

If I want to learn how to produce ePub3 ebooks where can I go to learn how to do it?

There's a Sigil plugin that'll automatically convert epub2 books to (epub2 compatible) epub3 books. However, unless you want to take advantage of epub3-only features, e.g. page numbers, (popup)* footnotes, advanced semantic features for readers with disabilities etc., it'd rather pointless to convert your epub2 books to epub3 books.

* Popup footnotes aren't actually part of the epub3 specs. It's up to the developer how to render them.

[JSWolf]

What surprises me is how developers stagnate their software. For example, Kobo is not using the latest RMSDK.

[PeterT]

RMSDK not RMDSK

Sent from my Nexus 7 using Tapatalk

[JSWolf]

Originally Posted by PeterT

RMSDK not RMDSK

Sent from my Nexus 7 using Tapatalk

Thanks for that catch.

[BetterRed]

Originally Posted by PeterT

RMSDK not RMDSK

So, a Root Mean Square in Denmark trumps a Required Markup Declaration in Slovakia

I wonder if GOOGL claims trademark rights on Alphabet soup

BR

[AlexBell]

Originally Posted by Doitsu

AFAIK, epub3 apps are supposed to also support epub2 books, and I haven't encountered an epub3 app that wouldn't read epub2 books.
Some epub apps, e.g. ADE 4.5/RMSDK 11.5 will actually use different rendering engines for epub2 and epub3 books.


There's a Sigil plugin that'll automatically convert epub2 books to (epub2 compatible) epub3 books. However, unless you want to take advantage of epub3-only features, e.g. page numbers, (popup)* footnotes, advanced semantic features for readers with disabilities etc., it'd rather pointless to convert your epub2 books to epub3 books.

* Popup footnotes aren't actually part of the epub3 specs. It's up to the developer how to render them.

Thanks, Doitsu. I may be the only ePub designer in the western world who doesn't use Sigil; I learned to do XHTML from doing websites, and still use the CoffeeCup website design software.

There doesn't seem to be any urgency to change my ways.

[DiapDealer]

I'm not pushing Sigil or anything, but after you know how--and can--build an epub from scratch, the knowledge gained is the only advantage--and that knowledge is invaluable. But it doesn't go away just because you start using an editor designed specifically for epubs.

There's no style points given for manually handling each and every tedious change to the opf/ncx/nav file required by changes to the other files. There's no style points for manually changing the url/anchor in every link throughput your xhtml files just because you've decided to rename an file.

Using an editor like Sigil (or calibre) also means it's impossible to forget to add the mimetype file to a zip archive. It means you don't need to worry about making sure the mimetype's the first member of the archive and is uncompressed. It means you don't have to worry about creating/maintaining zip archives at all.

Letting software manage the opf and the zip structure frees you from the mundane portions of epub building. It allows you to focus almost entirely on the xhtml/css. It allows you to work more efficiently.

And using Sigil doesn't mean you have to give up CoffeeCup as your XHTML editor. Sigil has allowed epub creators to use external editors for quite some time now.

But you're right, there's no urgency to change. Especially if you actually enjoy working harder/longer than you need to.
(That's not a personal dig. I realize there's many who adhere to a "if it ain't rough, it ain't right" type of philosophy.)