Adequacy of EPUB?

[Sarmat89]

EPUB seems to be the dominating format, but it is hardly adequate for the fiction.
It is based on HTML, which semantical elements are rudimentary and focused around computer manuals (tt, var, code, dd).
HTML mixes up logical and physical layout when creating the simplest fiction elements: letters, titlepages, poems, even chapter titles—they have to be imitated by CSS styles. If you take 5 EPUBs of similar structure, they will have 5 different ways to structure its elements.

Also EPUB cannot handle metadata: there is no support for genres, series, translations, artists...

Shouldn't the editors and publishers to embrace a new format which was designed with eBooks in mind?

[eschwartz]

EPUB was designed with ebooks in mind.
And it handles metadata just fine, as you would discover if you investigated how EPUB works. Notwithstanding that Dublin Core metadata hasn't standardized on many important concepts like what you mentioned.

CSS styles are The Right Way to define a logical layout for specific elements. Use a house style to make all the ebooks use the same underlying methodology.



But hey, if you think you can do better, go right ahead and show us.

[Sarmat89]

Originally Posted by eschwartz

And it handles metadata just fine

But there is still no way the user can find the books with covers by Vallejo or the available translations of a certain title. The user cannot properly group their books by universes, cycles, trilogies, etc.

CSS styles are The Right Way to define a logical layout for specific elements.

There is no way for user to make the chapter headings in their books centered, the poems set in smaller font, or code snippets in Consolas. The underlying HTML format does not know about poems, headings and code snippets, as they are just spans, p's and divs with no standard class or id names, and therefore no semantic roles.

[eschwartz]

Originally Posted by Sarmat89

But there is still no way the user can find the books with covers by Vallejo or the available translations of a certain title. The user cannot properly group their books by universes, cycles, trilogies, etc.

Sure you can. Get an ebook management application that allows you to define and store your own namespaced metadata types.

http://calibre-ebook.com

There is no way for user to make the chapter headings in their books centered, the poems set in smaller font, or code snippets in Consolas. The underlying HTML format does not know about poems, headings and code snippets, as they are just spans, p's and divs with no standard class or id names, and therefore no semantic roles.

That is not the question you originally asked.

And it is also unnecessary -- since the publisher should already have done so for you.




But once again, if you really feel that EPUB is lacking, feel free to invent your own competing format and convince the publishers to use it.

Or... you know... try to get them to use unified House Styles. Or modify them yourself, to suit yourself.

[Jellby]

Originally Posted by Sarmat89

But there is still no way the user can find the books with covers by Vallejo or the available translations of a certain title. The user cannot properly group their books by universes, cycles, trilogies, etc.

Even if those metadata fields were standardized, they would without any doubt be misused, left blank, filled with wrong information, etc.

There is no way for user to make the chapter headings in their books centered, the poems set in smaller font, or code snippets in Consolas.

Same as above. Chapter headings we have, with <h1>-<h6>, and you can see how often they are wrongly (or inconsistently) used. Poems, I agree, CSS needs better treatment of poetry requirements, but there is for instance <blockquote>, which should/could be used for letters (and even for poems, with additional formatting), and yet it's often ignored.

The problem is not the format, it's the people using it. Still, I agree the format could be improved with some additional metadata and formatting features, but publishers are more interested in multimedia stuff...

[eschwartz]

It is entirely a matter of standardization.

EPUB itself is perfectly adequate, even if some of the people who use it, aren't.
And a new format wouldn't change anything...

[Turtle91]

I'm not sure that the inadequacy, if any, could be blamed on ePub anyway. It seems most of the problems mentioned above are problems with Dublin Core metadata standards, or CSS standards. ePub just collects all those xhtml files into an organized grouping with a couple short admin files for navigation and organization.

[Arios]

I agree with you Turtle91, as well as Jellby and eschwartz, but I guess Sarmat89 wants to start a debate (being the devil's advocate?), because his assertions seem a 'tad' controversial .

[eschwartz]

Yup, that's why I said, actions speak louder than words -- let's see this proposed new format first, then we'll talk.

[JSWolf]

I would go with ePub 2 with some additions. ePub 3 needs to be scrapped. It was made to be flashy and is more complicated than it needs to be.

[Notjohn]

Given that Amazon seems to sell about 65 percent of e-books (though perhaps that stat is only for the US), I hardly think that epub is dominant.

Or perhaps you regard KF8 as epub-under-the-hood?

(Indeed, with the advent of KFX, the e-publishing world seems to be ever more Zon-centric.)

I will however certainly yield to your point about poetry. But perhaps that failure is less about epub than about e-books. Short of switching to fixed format, there doesn't seem to be any way for a digital product to curtsy to poets who think in terms of visual appearance on the page.

[JSWolf]

Originally Posted by Notjohn

Given that Amazon seems to sell about 65 percent of e-books (though perhaps that stat is only for the US), I hardly think that epub is dominant.

Sorry, but you are wrong here. ePub is the dominant format. You cannot go by just the US only. World wide ePub is dominant.

[Sarmat89]

Originally Posted by eschwartz

That is not the question you originally asked.
And it is also unnecessary -- since the publisher should already have done so for you.

It is—if HTML cannot provide semantic markup, users cannot customize it. Also, this way of thought is ridiculous—should we also not to have a customizable typeface, body text alignment and color schemes, because the publisher has already decided on them for us?

As for the format, we already have the tools we need: XML (not the obsolete (X)HTML, 5 or not), CSS and OPC to bring it all together. What we do not have, is the will coming from EBook consumers, not some 'open' 'standards' committee.

[Terisa de morgan]

XML? What's that? A tool with no use without a language over it, a COMMON language. XML itself is the same than C or java or python, you have to build over it, xhtml, although obsolete, is an step over it. And what consumer is going to design it?

[eschwartz]

Originally Posted by Sarmat89

It is—if HTML cannot provide semantic markup, users cannot customize it. Also, this way of thought is ridiculous—should we also not to have a customizable typeface, body text alignment and color schemes, because the publisher has already decided on them for us?

No we shouldn't.

Random color schemes in my books are what I can only call hideous.

And customizing the default, base typeface and text alignment is one thing -- customizing the overridden, fragment-specific values is another thing entirely.

And once again, HTML is the absolute essence of semantic markup.
The fact that there is no standardized semantic markup for "poem" is not a flaw in HTML, XHTML, XHTML5, or EPUB.

As you have already been informed, HTML is so semantically complete that it actually does have a "Chapter Title" semantic, and a "letter" semantic as well!
There is even a dedicated "code" tag for computer code snippets...

As for the format, we already have the tools we need: XML (not the obsolete (X)HTML, 5 or not), CSS and OPC to bring it all together. What we do not have, is the will coming from EBook consumers, not some 'open' 'standards' committee.

I would really like to know how you formed the conclusion that HTML5 of all things is "obsolete".


And apparently we have plenty of will, and bright ideas too -- from you.
So I will call you on it once more.
You go write a first draft of your proposed new format. Then we'll talk.

Given how little you seem to know about HTML (the thing you are mistakenly complaining about), I cannot think you will be very successful.