Adequacy of EPUB?

[Sarmat89]

Originally Posted by Hitch

I have an exercise book in now, with 450+ images, that we've just remade for the nth time, because--wait for it--our final (*ha) eBook files don't resemble the print book enough.

No one cares about extremities. 95% of books out there do not have 400 images and consist of logical elements unaffected by design choices.

[eschwartz]

Originally Posted by Sarmat89

That's absurd. You connect the template, assign styles with predefined names, and the converted creates the XML elements basing on those styles, exactly like before. Paragraphs with 'Epigraph' styles are gathered in <epigraph> elements, italics get converted to <em>s... It is not a problem.

Well, maybe you could stop instinctively calling everything absurd and listen to what I said.


Currently, styles --> CSS classes.
Styles are applied to paragraphs, and CSS classes are applied to <p> tags.


But you'd much rather that an EPUB converter parses the styles to match them up to YOUR arbitrary list, then walk up to the parent node and just automagically turn it into a different element. And what happens to the other styles?

The two biggest problems with that are a) I am the wizard here, not you, and b) (I'm being serious this time) it seems you hate the idea of ebook producers being allowed to define their own CSS.
(Also a major problem is the need to actually write new ebook converters that can jump through the hoops you want. Do you think code grows on trees?)
(Also a major problem is the fact that you want to force everyone to learn a totally new and radically different approach to designing their books. But you have steadfastly ignored everyone who said so.)


That being the case, this discussion is a non-starter.
You think publisher CSS is bad.
Publishers think publisher CSS is good.

The IDPF agrees with the publishers. I agree with the publishers. Hitch agrees with the publishers. JSWolf agrees with the publishers. Jellby agrees with the publishers. Toxaris agrees with the publishers. In fact, I have never heard of anyone other than you who disagrees with the publishers.

It's kind of like, oh, that your values system has an extreme dissonance with every other values system on the planet.

[eschwartz]

Originally Posted by Sarmat89

No one cares about extremities. 95% of books out there do not have 400 images and consist of logical elements unaffected by design choices.

How utterly rude.

Did you just say no one cares about the fundamental model upon which her entire livelihood is based?

I am pretty sure she cares, as do her employees, and heck, all the MR regulars who value her wisdom and personality.


But personal rudeness aside, 95% of books make 1% of the noise and only a little more impact in the publishing world rather than the reading world.

[JSWolf]

Originally Posted by Hitch

That's retinue to you, knave. "...her retinue at MobileRead." I think you should be the Lord High Enforcer of Standards, Wolfie, my sweet.

In that case, I hereby call for all Readers to support ePub so we no longer have a format war.

[Sarmat89]

Originally Posted by eschwartz

But you'd much rather that an EPUB converter parses the styles to match them up to YOUR arbitrary list, then walk up to the parent node and just automagically turn it into a different element. And what happens to the other styles?

1. That's how DOM works. 2. Which other styles? There is no difference between styling <p>s and styling <p>s and <poem>s. You want a heading, you use 2 or 3 styles to make it. What do you need 'extra' styles for?

I am the wizard here, not you

Personal attacks? How quaint.

you want to force everyone to learn a totally new and radically different approach

Assigning styles in a text editor or clicking a toolbar in GUI editor is not radically different.

You think publisher CSS is bad.

No. I think CSS should add to logical layout, not define it.

I still don't know where did you get so many misconceptions about XML. In fact it is like XHTML, only better. They can define the same block/run model. They are interpreted by readers in the same way. The only difference is the powerless HTML with few Ebook-specific extensions and the powerful markup tailored for books.

[Toxaris]

Originally Posted by Sarmat89

That's blatantly false.

No, it isn't. Publishers don't care about the metadata other than author, title, language, ISBN and that is about it. Of those, the author, title and language are mandatory. Sometimes they also add a custom (blasphemy!) metadata for a kind of watermark. They rather put it in a colophon for a number of reasons. Most important reasons are that readers (the people, not the devices) have a bigger chance of seeing it and since they work from the same source for the e-book and physical book.
If you claim it is false, please show some real proof besides your opinion.

Originally Posted by Sarmat89

If EPUB mandates the use of DC vocabulary in plain text form, it is problem of EPUB. There are simply no alternatives to it.

Yes there is. Custom metadata, there is nothing withholding publishers to agree amongst themselves to a standard set. They won't, because they don't care.

Originally Posted by Sarmat89

Because they cannot rely on EPUB metadata. With clearly defined scheme, that support will be trivial.

See above. Your facts are wrong.

Originally Posted by Sarmat89

"John Smith", "Arthur Conan Doyle", "Johannes van der Waals" and "Murakami Haruki" all parse in different way, and there is no way for library software to do that automatically without errors.

Yes there is and is in use in many libraries already. There are clear rules about these. Believe me, I come from a country with a lot of last names consisting out of multiple words. It can and is done multiple times easily. Also, you can use the 'store-as' as well. But publishers use that of course already since they care about metadata, right?

Originally Posted by Sarmat89

I still don't know where did you get so many misconceptions about XML. In fact it is like XHTML, only better. They can define the same block/run model. They are interpreted by readers in the same way. The only difference is the powerless HTML with few Ebook-specific extensions and the powerful markup tailored for books.

We still don't know where your misconception about XML comes from. XML is nothing. It is a hollow, empty format. It can only give substance with a schema or DTD defining it. What you are proposing will make things much more complex with NO gain at all for 98% of the people using or reading it.
The basis you are suggesting (more like demanding) has been the source of many tries in the past. NONE has worked or gotten a large share.

[PeterT]

This whole thread reminds of this one --> What "Cleaning Up" Do Project Gutenberg Texts Need [closed].

[eschwartz]

Originally Posted by Sarmat89

1. That's how DOM works. 2. Which other styles? There is no difference between styling <p>s and styling <p>s and <poem>s. You want a heading, you use 2 or 3 styles to make it. What do you need 'extra' styles for?

My problem is that that is a lot of code which doesn't currently exist, with no justification to why it is needed, and no adequate explanation for what you expect people to do, if they want to do something that doesn't have a semantic element you have defined.

Personal attacks? How quaint.

I apologize for injecting humor into my post, I didn't realize you wouldn't take humor well.

Assigning styles in a text editor or clicking a toolbar in GUI editor is not radically different.

That's how people are currently doing it.

But your suggestion is that people change their whole process to focus on what idealism to call a particular section by, rather than styling it the way it should look.
People who can currently make a book that doesn't conform to your expectations, will have to spend all their time figuring out what to call something, rather than just defining it themselves.

No. I think CSS should add to logical layout, not define it.

OK then. Since you have been very confusing on this point, let me ask you straight out.

When and how do you propose that CSS be used?

I still don't know where did you get so many misconceptions about XML. In fact it is like XHTML, only better. They can define the same block/run model. They are interpreted by readers in the same way. The only difference is the powerless HTML with few Ebook-specific extensions and the powerful markup tailored for books.

Um, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no.
You seem to have a love affair with XML, but as everyone else in this thread has repeatedly said, the only difference between XML and XHTML is that XHTML has a schema attached to make it useful.
XML on its own cannot be interpreted at all.

And you keep saying XML will be better than XHTML, without defining why or what schema will be the answer, which makes me doubt* you have an adequate answer.


* -- OK I lie. I know you don't have an answer.

[doubleshuffle]

Originally Posted by eschwartz

I apologize for injecting humor into my post, I didn't realize you wouldn't take humor well.

That did come as a surprise, right?

[eschwartz]

Originally Posted by doubleshuffle

That did come as a surprise, right?

Yeah, I know. Who'd've thought @Sarmat89, of all people, wouldn't appreciate my humor?

[phillipgessert]

Originally Posted by Sarmat89

No one cares about extremities. 95% of books out there do not have 400 images and consist of logical elements unaffected by design choices.

I don't think a format that requires a fallback format for outliers sounds very practical. I also think every element in every book is affected by design choices.

[Solitaire1]

eschwartz wrote the following as part of a post:

Originally Posted by eschwartz

Um, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no, no.
You seem to have a love affair with XML, but as everyone else in this thread has repeatedly said, the only difference between XML and XHTML is that XHTML has a schema attached to make it useful.
XML on its own cannot be interpreted at all.

And you keep saying XML will be better than XHTML, without defining why or what schema will be the answer, which makes me doubt* you have an adequate answer.

My understanding is that XHTML is simply an HTML document formatted as a valid XML document. Due to that, XHTML has none of the formatting fuzziness that is tolerated in HTML.

[eschwartz]

Originally Posted by Solitaire1

eschwartz wrote the following as part of a post:



My understanding is that XHTML is simply an HTML document formatted as a valid XML document. Due to that, XHTML has none of the formatting fuzziness that is tolerated in HTML.

Yes, that is true.

Or to put it another way, it is an XML document defined by the HTML schema.

[Hitch]

Originally Posted by Solitaire1

eschwartz wrote the following as part of a post:



My understanding is that XHTML is simply an HTML document formatted as a valid XML document. Due to that, XHTML has none of the formatting fuzziness that is tolerated in HTML.

Originally Posted by eschwartz

Yes, that is true.

Or to put it another way, it is an XML document defined by the HTML schema.

Yes--and the essential part of this is, it's XML that carries its schema with it. For all intents and purposes, that is.

Instead of having an XML file with a schema that is not carried with it, but is, instead, divined by the individual device, based on the user's desires, the schema (the CSS, effectively) travels therewith.

Sarmat89's issue, by and large (to distill it) is that a formatter can call this:

"Copyright 1989"

Anything that s/he wants. It will, generally, be a <p> code, carrying a CSS styling command. If the formatter is experienced and knows what they're doing, s/he will call it ".copyright" as the class name. This does two things: makes it easy to troubleshoot when things go wrong, and it shows that the formatter is thinking about structure, as well as appearance.

Sarmat89, however, wants this formatted as its own element. So that it would be (let's say) <copyright>. An element, like a paragraph. And, generally speaking, for very experienced bookmakers of the e-variety, that's not really difficult to do. It would be time-consuming, compared to using p, as there would be a ton of elements to memorize. I know some bookmakers that do use XML and then parse it with an XSLT sheet to create an ePUB. But what Sarmat wants is for everyone to be forced to use XML, primarily, it seems, because he wishes to be able to see various things--by and large, metadata--that isn't being displayed or used or available, now, in ePUB.

A change like this would, fundamentally, change bookmaking for eBooks. Sarmat89 will say that it won't; but it shall. He'll say that you can make books in XML and then convert them using an XSLT to create ePUBs or (insert book format name here). BUT, he's talking out of both sides of his mouth, because he also asserts that formatting books this way will also allow the user to change how it's seen. To tell his device to display an epigraph this way and a newspaper column that way; to show the Chapter heads left-aligned, for example, as opposed to the center-aligned styling intended by the bookmaker.

Thus, we have cognitive dissonance. Either we're discussing

• bookmakers outputting pure XML files, which would allow the users to style them however they want, using their own XSLT sheets (defaults, presumably, that would be installed on the devices),
• or, we're discussing using XML, to then be converted with XSLT sheets, to create the very same eBook formats that already exist.

And, in either event--neither guarantees that a bookmaker or publisher will complete all the metadata as Sarmat89 desires. As eschwartz pointed out, repeatedly, you can't make a bookmaker NOT type "aaaaaaa" in any textual field.

Thus, this merry-go-round continues to turn, turn, turn turn. To every season turn, turn, turn...ooops, sorry, showing my age there for a moment. ;-) Thus, we seem to be going in rather endless circles.

Offered solely FWIW.

Hitch

[HarryT]

Originally Posted by Sarmat89

No one cares about extremities. 95% of books out there do not have 400 images and consist of logical elements unaffected by design choices.

You'd be a fool to dismiss what Hitch says. She is the most experienced ebook creator you're ever likely to come across. You really should treat what she tells you with a little respect.