OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

# docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook] Docbook for ePub and print versions?

• From: Peter Flynn <peter@silmaril.ie>
• To: docbook@lists.oasis-open.org
• Date: Wed, 26 Oct 2011 22:34:11 +0100

On 18/10/11 20:18, Thomas Schraitle wrote:

Hi Bob,

Am Dienstag, 18. Oktober 2011, 10:55:48 schrieb Bob Plantz:

[...]
Of course, I want to have only one source for the material. So I am
looking for the best tool chain that will allow me to produce both an
ePub and a pdf (for printing) from the same source. So far my choices
seem to be:

1. Restructuredtext for the source, which would be processed with docutils.
I like the simplicity of Restructuredtext, but it seems to lack (at
this time) good tools for automatically numbering figures, exercises,
equations, etc.

2. DocBook for the source, which can produce both pdf and HTML.
I've heard that DocBook can be difficult to work with for complex
documents.


Well, depends how you define "difficult". ;)  If you are get used to word
processors like Open Office, Word, etc. DocBook *might* be a bit unfamiliar.



And it depends on how complex is "complex". DocBook was designed expressly for this kind of document, so it has all the markup you will need.


The advantage is that once the document is in XML, generating multiple outputs is several orders of magnitude easier than doing it from LaTeX source (or Word, or...). The pain is in getting the document into DocBook format to start with, but you only have to do that once.

>> 2. DocBook for the source, which can produce both pdf and HTML.


And it can of course be used to [re-]generate LaTeX source, if you prefer to use that for creating the PDF rather than the XSL:FO method.


3. LyX for the source, which can produce both pdf and HTML.
The conversion from LaTeX to LyX will be as difficult as 1 and 2,
and it seems that all I get is a somewhat WYSIWIG interface to work
with, at the expense of adding another layer.

As you can see from my comments, I'm leaning toward choice 2. I know
that any of the choices will be lots of work for me. But I'm retired,
and I enjoy doing this stuff. Also, my work may provide some input into
the overall problem of creating technical eBooks.



If your LaTeX is well-formed, regular (ie consistent) and does not have a lot of home-grown macros and manual-intervention formatting, it isn't hard to convert it to XML (eg DocBook), just tedious. Some good scripts, repeat-replace edits, and keyboard-recording macros in (eg) Emacs will probably do most of it.


On the other hand, if the source is untidy (because LaTeX often doesn't need to care about irregularities in spacing), or if it uses a lot of inconsistently-applied or ambiguous macros, or if it conflates different semantics to a single macro[1] then it will be a lot more work.


[1] By this I mean using (for example) \emph for its ability to italicise or even font-swap between roman and italic, rather than because it denotes emphasis (what is known in XML circles as "tag-abuse"). This is a common editing problem among LaTeX users converting to more exacting forms of markup, and is outlined in
http://latex.silmaril.ie/formattinginformation/typographics.html#logic

///Peter


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]