Re: Antwort: Re: DAVENPORT: Three more Questions.

[Konrad Hinsen <hinsen@cnrs-orleans.fr>]

Norman Walsh <ndw@nwalsh.com> wrote:

> It's much worse than a problem of education. Graphical markup is
> largely useless for automated processing of documents. Because

Fine, so ignore it. In a mixed structural/graphical markup, graphical
markup should be considered a set of hints to the typesetting engine,
nothing more. It's still nice to have.

> it into something more useful. Two of the big benefits of
> structured markup are:

Sure, I agree, otherwise I wouldn't subscribe to this list. But most
DocBook documents will at some point be printed and/or converted to
HTML, and the vast majority of readers will never see anything but
these final presentations. My motivation for using DocBook is to have
the advantages of structural markup *in addition* to proper
typesetting, not instead of.

> This is a bad example for a couple of reasons. First, the menu
> item "italic" doesn't do one thing (probably), it does many

OK, maybe it's a bad example, but give me some time and I'll come up
with a better one. The point is that sometimes the author *must* have
control over presentation aspects.

> I know. It's a pity. Maybe XSL will be more approachable. On the
> other hand, most people dramatically overestimate the extent to
> which any particular effect is "essential".

It's not so much a particular effect as the absence of some particular
effect. For example, what made me question the usefulness of DocBook
was my first sample text converted to PostScript via Jade and JadeTex.
It looked simply ugly, ignoring basic typesetting rules such as
avoiding page breaks after a section heading. And due to the
complexity of the chain of transformations, I had no hope of analyzing
and solving this problem in a reasonable time.

Now you will perhaps reply that this is a problem of early release
software, and I agree. But the general problem remains: I see the
output, don't like it, and want this or that changed. My chance of
actually getting this done is very small.

> I have a theory about authors: they have no business even
> thinking about the presentation of thier documents, let alone
> tinkering with it. That's not their job. Authors are supposed to

It's exactly what you call it: theory ;-)

When typesetting was still done by typesetters instead of computers,
it happened that an author was requested to change the text of his
book because the original text could not be broken into paragraphs in
an aesthetically pleasing way.

Nowadays, the distinction between author and typesetter gets blurred
even more. When I submit a scientific article to a journal, I am
expected to provide it in a format compatible with the journal's
convention, down to details such as style of section headings. For
some aspects, such as mathematical equations, I take the full
responsibility because no typesetter could do it.

With Web publishing, it gets even worse. Often I want both a printed
version and an HTML version of some document. But the text of these
two versions should not necessarily be identical, for example
in references to other documents. In a printed version, I'd want to
see
        ... this was shown by Miller et al. [1]
        ...
        [1] Miller et al., ..., also available online at
            http....

whereas a HTML version should read

        ... this was shown by <a href="http:...">Miller et al.</a>

and I might even want to add a link to some download site of a
program.

Or take another example: tables. In order to prepare a readable table,
I simply must know the constraints imposed by page size and layout.
Same for illustrations. And if I write a reference manual for some
program library, there might be a requirement that each function
description is limited to one page.

In short, it is impossible to separate content from presentation
in general. It can be done in most cases, but there should be a
mechanism for dealing with exceptions.

> You've never tried to drag LaTeX documents uphill into meaningful
> structured documents, I can tell. Sometimes {\it word} means that

Indeed. But I have always been able to get the output that I wanted or
that was expected from me, and it was never difficult to change some
global definitions in order to produce a particular layout, thanks to
very sparing use of graphical markup.
-- 
-------------------------------------------------------------------------------
Konrad Hinsen                            | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron                       | Fax:  +33-2.38.63.15.17
45071 Orleans Cedex 2                    | Deutsch/Esperanto/English/
France                                   | Nederlands/Francais
-------------------------------------------------------------------------------