Master Format for multi-format eBook Generation?

[cerement]

See Kirtai's response above ...

Originally Posted by JSWolf

Unless the eBook in question has need beyond the bounds of HTML, then HTML is the optimum format for multiple format generation.

HTML relies on conventions, not standards and is not stringent enough to minimize errors that creep in during transposition to other formats. You end up using class="aaa" far more often to get things to behave. Jon Noring has commented already on the shortcomings of XHTML when dealing with eBooks.

Originally Posted by JSWolf

Calibre can take that HTML and generate ePub, LRF, LIT, and Mobipocket. So why would you need this nonstandard DTBook in most cases?

DTBook, TEI, DocBook are all standards, are all far more rigorous than (X)HTML. DocBook (and it's parent SGML) have been around far longer than HTML. ePub allows the primary text component to be in either DTBook or XHTML (but falls short with the "packing list" not allowing non-linear reading the way DITA does). Whereas the HTML generated by many WYSIWYG editors is a hideously bloated tag soup that wastes Calibre's processing features, can easily break conversions, and results in files MANY times larger than necessary (MSWord for a long time would wrap <font face="xxx" size="yyy"> tags around every single paragraph).

Most of these formats also have the advantage of freely available tools (including a massive toolset on O'Reilly for DocBook) for conversion to several outputs, and if the tool doesn't exist, some work with XSLT can handle those conversions.

TLDR: HTML is fine for an end format, but it is nowhere near clean enough for the beginning format.

[Kirtai]

Now that I think about it, ePub containing DTBook might be the best interim standard format for sequential texts like novels and such until a better format becomes available.
Especially if Calibre and other tools start supporting it. Which they should

[Sweetpea]

Originally Posted by cerement

Whereas the HTML generated by many WYSIWYG editors is a hideously bloated tag soup that wastes Calibre's processing features, can easily break conversions, and results in files MANY times larger than necessary (MSWord for a long time would wrap <font face="xxx" size="yyy"> tags around every single paragraph).

I wouldn't ever use a WYSIWYG editor for something you'd like to call a source format. And I put MSWord in that group as well (actually, any wordprocessor).

From what I saw (took a quick look) from that DTBook, but that too is just an XML with a DTD (which XHTML is too).


I still prefer XHTML for two reasons. One, I can edit it with notepad if needs be and I can "preview" it in a browser. As long as you don't use a WYSIWYG editor HTML is perfect for the job.


------

Actually, I'd advice against using a WYSIWYG or MSWord (or any other wordprocessor) for creating HTML files at all...

[Kirtai]

As another option, has anyone looked at Fictionbook2 as a master format?

[Kirtai]

I've been giving this some more thought and it occurs to me that maybe the best approach would be to build better tools and use the best format for each type of book.

e.g.
For linear books like fiction, use DTBook or Fictionbook2
For technical books, use DocBook
For topic/map books like encyclopedias and recipe books, use DITA
For complex office documents, use OpenDoc.
For complex books that don't fit into any other category, use TEI

A single toolchain could convert all of these into any output format, or readers could even handle them directly. Though this might be a bit pie in the sky

I've heard that the Rosetta tools go even further by storing the document in a database format from which it can be exported in any format, but I've been unable to find any further information on that.

[cerement]

Originally Posted by Kirtai

I've heard that the Rosetta tools go even further by storing the document in a database format from which it can be exported in any format, but I've been unable to find any further information on that.

TomeRaider on Palm basically did that, everything from short linear texts to huge encyclopedias were stored as databases. DITA has the advantage in this respect in that it makes it very easy to chunk and reassemble anything and then integrate the chunks with a CMS of your choice (ex. DITA for WordPress) to handle customized delivery.

[Hadrien]

If you're capable of writing your own XSLT, it doesn't really matter which DTD you're using, you can even create your own.

There's no perfect fit, each DTD will only solve a limited sub-set of problems.
The easiest one to work with is probably DTBook since it's basically XHTML with just a few semantic elements. TEI is incredibly powerful but might be overkill for what most people need.

[Kirtai]

Originally Posted by Hadrien

If you're capable of writing your own XSLT, it doesn't really matter which DTD you're using, you can even create your own.

There's no perfect fit, each DTD will only solve a limited sub-set of problems.
The easiest one to work with is probably DTBook since it's basically XHTML with just a few semantic elements. TEI is incredibly powerful but might be overkill for what most people need.

I expect this is what will happen. It also has the advantage of pushing most of the complexity into the tools which is exactly where it should be.
OTOH, it will require a lot of work for those of us who want to do it now, before the tools mature. I don't know if I'm happy or sad about that

[cerement]

Originally Posted by Kirtai

OTOH, it will require a lot of work for those of us who want to do it now, before the tools mature. I don't know if I'm happy or sad about that

That's the biggest problem, I'm looking for a so-called "master format" when the whole publishing industry is still in it's infancy as far as electronic books are concerned

Originally Posted by Hadrien

There's no perfect fit, each DTD will only solve a limited sub-set of problems. The easiest one to work with is probably DTBook since it's basically XHTML with just a few semantic elements. TEI is incredibly powerful but might be overkill for what most people need.

Since we've managed to drag you into this topic, what format does FeedBooks have the least problem ingesting? Or, better still, which format loses the least when uploaded and converted to FeedBooks internal format?

[Hadrien]

Originally Posted by cerement

Since we've managed to drag you into this topic, what format does FeedBooks have the least problem ingesting? Or, better still, which format loses the least when uploaded and converted to FeedBooks internal format?

The closest one would be DTBook as we're essentially adding some semantics to XHTML (parts/chapters/sections, notes etc.). The semantic elements though are not exactly expressed in the markup, as the system is more designed around the idea of using multiple chunks rather than a single source file.

[cerement]

Originally Posted by Hadrien

The semantic elements though are not exactly expressed in the markup, as the system is more designed around the idea of using multiple chunks rather than a single source file.

Heh, that's been my side challenge the last couple of weeks. I have had no problem finding chunked XHTML ePub samples, but so far I'm having no luck finding a chunked DTBook ePub sample. Even the ePub tutorials all seem to focus on XHTML with nothing more than a side note "oh, you could also use DTBook if you wanted" ...

[Hadrien]

Originally Posted by cerement

Heh, that's been my side challenge the last couple of weeks. I have had no problem finding chunked XHTML ePub samples, but so far I'm having no luck finding a chunked DTBook ePub sample. Even the ePub tutorials all seem to focus on XHTML with nothing more than a side note "oh, you could also use DTBook if you wanted" ...

I'm not even sure that you could really chunk pure DTBook as you need to use the <levelx> elements (http://www.daisy.org/z3986/structure...ts.html#level1).

[cerement]

Originally Posted by Hadrien

I'm not even sure that you could really chunk pure DTBook as you need to use the <levelx> elements (http://www.daisy.org/z3986/structure...ts.html#level1).

From what I've been able to pull out of the DAISY 3 Structure Guidelines, you can have multipart books using DTBook, each part still has to have the necessary headers and the "book" is logically segmented (you can't just randomly segment a file into arbitrary chunks).

Ex.

<dtbook>
    <head>
    </head>
    <book>
        <bodymatter>
            <level1 class="chapter">
                <h1>Chapter 1</h2>
                <p>(paragraph tags or any block level element)</p>
            </level1>
        </bodymatter>
    </book>
</dtbook>

<dtbook>
    <head>
    </head>
    <book>
        <bodymatter>
            <level1 class="chapter">
                <h1>Chapter 2</h2>
                <p>(paragraph tags or any block level element)</p>
            </level1>
        </bodymatter>
    </book>
</dtbook>

[Kirtai]

From the sounds of things, it seems that the best approach for now might be to simply pick a suitable format (e.g. DTBook for linear text, DITA for topic oriented, or DITA/TEI-lite for all) and learn enough XSLT to be able to convert them into whatever godformat that's eventually settled on.
Does that about cover it?