[Hitch]

Originally Posted by Sarmat89

End user should not do metadata hunt for himself. It should not rely on 3rd party utilities to keep his own databases. The book he gets from the store must be functionally complete by its own.
Custom metadata are useless if they are not standard. If DC was not adequate, the spec authors should have created the additional dictionaries.

Well, now we're simply at "is too, is not." It's absurd. You want 100 more types of metadata than I do, for my own books. Jane will want something else. That's the entire POINT of custom metadata. No one--no one--will ever anticipate every type of metadata that some gearhead wants. It's ridiculous. I know someone who actually categorizes her romances by what TYPE of romance it is. You think that XML will address that?

A specific format allows to do that and more in a fraction of effort. Instead of designing and re-using stylesheets for every book... you can focus on design, not on stupid technicalities and 'layout tweaking'. It's a pure profit.

(Sorry...the "pure profit" part left me gasping for air.)

Uh, no. Look, my friend: conversion is never going to be automated. How do I know this? I've tried. Everyone here, including my hero Tox, has tried to automate conversion. It does NOT MATTER whether you want to wrap <simpara> tags around a paragraph, or "p.norm" tags.

The conversion still has to be done with your hands and eyeballs, because--this seems to be the part that people who don't do this daily never understand--you will NEVER get the same file twice. NEVER. You'll get what I get: people who type like they're using a typewriter, hitting "enter" at the end of each LINE, not paragraph. You'll get people who use tabs. People who use "normal" for every element in the book. People who manually type all the superscripted footnote numbers, and manually position the corresponding note at the bottom of the page--for hundreds, if not thousands, of footnotes. Whether one uses XML or HTML for fixing those footnotes shan't make one iota's difference in what it takes to fix it.

Do you realize that what you're arguing is that typing ONE type of tag is faster and better than typing another? You're constantly conflating your desire for METADATA with the actual bookmaking process. It's the fatal flaw in your argument.

Speaking for those of us that DO do this everyday, none of us are sitting there writing custom CSS for *every* book. That's a daft idea on its face. I have House CSS, that we use for book after book. For both fiction and non-fiction, we have standarized stylesheets, from which we use the SAME CSS classes over and over. Why on earth do you think it makes two farts' worth of difference to the bookmaker whether she types <p>yadda</p> or <simpara>yadda</simpara>? Clue: it doesn't. In fact, I'd point out that XML, specifically book schema, has what, 101 child elements for a simpara, alone? Yeah, MUCH better.

You completely misunderstand how professionals make books, if you think that they get a source file and then sit around writing up custom CSS for each. That's daft. We may modify the appearance, for a given type of list; but the NAMING conventions--just like XML schema--stay the same.

More importantly, you're deliberately making it sound "easier" and "simpler," when it's SSDD. (Same Stuff, Different Day) to the bookmaker. It's of no mind whatsoever, if you have to look at a file (let's say, a Word file of a fiction ms, to make it easy) and decide whether it's a para, a simpara or a formalpara, (XML) versus looking at it and deciding that you're going to use a regular paragraph <p>, or some other type of paragraph <1after, 2after, first> that you have already created, long before, in a standardized CSS.

What idiot would NOT use a standarized CSS, even if it was an author who had 4 books to convert? Hell, back in 2009-10, it was the FIRST thing I did, once I realized I was going to be doing this for a while; I created a standardized CSS that I (still) use to this day, although obviously, it's been tweaked to keep up with changing devices and standards.

Conversion is only the first step to the book. Than you can point to things, and say, 'it's a letter salutations', 'it's a chapter number', 'it is a footnote', instead of making up stylesheet classes for paragraphs. Much simpler, isn't it?

Again, you keep surmising that every book made is the FIRST book ever made by that person, and that they're having to create CSS for the first time, ever. That's begging the question, to try to win the debate.

Either we're discussing commercial/repeat bookmakers, in which case the assumption is simply wrong, or we're discussing amateur, first-time bookmakers, in which case, surely you cannot disagree that learning all the ins-and-outs of XML Schema would be FAR harder for them, then the HTML-XHTML standards currently in place?

And if the bookmaker is COMPETENT, no, conversion isn't the first step; it's the entirety. If you mean, when you say "conversion," exporting the typed material to some other format, then, yes: "conversion" is the first step. But the real work is the formatting (aka conversion), and that is not made one iota simpler by using XML over XHTML or HTML. You're simply wrong.

AFAIK Kindle guidelines prohibit setting fonts for body text for customization and accessibility reasons. You don't need fancy fonts in E-book. Not all readers support embedded fonts. No one stop you from assigning font to "chapter>title label" in the exact same way you assign it to "p.chapter_no_2a".

That's right--two different ways--neither better than the other--for doing EXACTLY THE SAME THING. This is what we have all been saying, since the beginning of this discussion. It's not faster to do one over the other, and the result for the end reader is PRECISELY the same. You persist in trying to argue that XML is better for the BOOKS, which is a losing argument, when all you care about is categorization and searching on metadata and semantics. The XML/XHTML portion of this discussion is not winning the debate, because we all know that it's 6 of one, half-dozen of the other, for the bookmaker.

There's no longer a prohibition against using fonts (for Amazon/KDP). Has not been in some time. The only "rule" is, don't embed fonts that are already on the devices. My firm does a ton of WL (white label) work, and we embed fonts all week long.

The difference is you don't know what you will get if you didn't do it in HTML; with a specific format, the user will have a nice, reasonable default from his reader+user stylesheets.

Hunh? What do you mean? "You don't know what you will get if you didn't do it in HTML?" Of course you don't. How the hell else would you "embed" fonts? You're either working in HTML/HXTML, or some variant, because other mechanisms can't carry the entire font file. I literally don't understand your meaning.

HTML was intended to eventually replace TROFF.

Hmmm. As was (wait for it) DOCBOOK, way back when.

I think that you are still failing to make your case. You have yet to convince anyone here--and we're a pretty open-minded crew around here, if you overlook a person or two--that your idea of using XML will somehow improve bookmaking ITSELF. The whole semantics thing, frankly, seems to be YOUR hangup. You want to be able to categorize the books that you buy or make down to the gnat's ass. Fine, go ahead and do that. You can do it with Calibre, or by using the DC that's already available, IN the Spec. The fact that readers don't use it--that's not the ePUB Spec's issue.

I now want to know what books you've converted, and what tools you use to do the job, because honestly, from a bookmaker's standpoint, your argument doesn't hold water. I find it very hard to believe that you've made a lot of books, or that you're making them in code, because you'd know that the difference between one set of tags and another is moot. You wouldn't have made that argument.

You really need to stick to the argument that might hold water--that you WANT more metadata. Whether or not it's "better;" well, that's the argument you need to make. Not that YOU want it; but why it's better for the whole industry. The fact that you want it is nice, but hardly compelling. You need to make arguments that state facts, not opinions, if you want to sway other people's opinions. So far, you keep repeating what you're saying, that using XML or XML scheme is "better" without showing us, or demonstrating to us, WHY it's better. You claimed that there were plenty of XML readers, which there are not; you claimed that there are easily-available WYSIWYG XML editors, which there are not. You claimed that you are not talking about DocBook, but there's not one iota of difference between the old DocBook standards, and what you've said you want. (Don't believe me? Try this: http://www.docbook.org/tdg5/en/html/ch02.html ).

One last point: you keep ignoring the fact that DocBook WAS here. It came, and it went. It didn't stay. Assuming arguendo that your position is correct--that XML is "better," then why on earth didn't DocBook stick? Why did it fade into the sunset? Why isn't EVERYBODY using DocBook to make ebooks???? Answer THAT one, while you're at it.

So...we will all be here, no doubt, when you come back with your next assertions. Maybe.