Re: alternative sgmltools?

[Gary Lawrence Murphy <garym@canada.com>]

>>>>> "H" == Hugo van der Kooij <Hugo.van.der.Kooij@caiw.nl> writes:

    >> - Is there decent support for mathematical formulae in DocBook?

    H> No. For computer documentation this is not deemed
    H> nescessary. If you need maths you must stick with LaTeX.

So far as I know, it's deemed necessary, but just not available at
this time.  Math can be done as an image and imported as a bitmap.
Yes, I know, this sucks, and I hate it too.

    >> - What is situation with non English languages and DocBook?

psgml-mode defines many character entities for European languages,
but it does not have the abilities of LaTeX with respect to other
alphabets.  LaTeX will even speak Klingon.

We need to understand some basic truths:

LaTeX is a typesetting system, designed to empower mathematicians to
typeset their own material and avoid misunderstandings by
non-mathematician typersetters.  TeX was _forced_ into labour as a
documentation tool, it was never intended as a general purpose
documentation language (nroff, however, was, but does anyone remember
how to uyse it?)  Because TeX/LaTeX includes Metafont, it is emmensely
powerful for rendering any collections of collections of structured
two-dimensional planes of spline-vector-drawn symbol images.

DocBook is not a typesetting system.  It is the opposite.  It is a
means for creating and maintaining knowledge structures, completely
independent of all concerns for the layout or the contents of those
structures.  DocBook is only concerned with labelling bits with
attributes and nesting those labelled bits inside other labelled bits.
It has no concept of a 'font' and the bits between two DocBook tags
can be peanut butter or DNA for all DocBook knows or cares.

The confusion arrises when we mistakenly look at LaTeX's ability to
create abstract names for fonts. The similarity is superficial: Both
systems let you call one block of character strings "code" and
globally change your mind about what that means by simply redefining
"code" in one location.  This leads us to the erroneous conclusion
that LaTeX lets us seperate content from presentation.  Nothing could
be further from the truth.

LaTeX is keenly aware of what occurs between tags because font
generation is at the core of its being.  LaTeX needs to know all sorts
of things, and as a result, who hasn't created a custom cplusplus def
to render the plus signs just right? DocBook, on the other hand, has
no idea whatsoever of how the information is going to be used or
rendered: that is Jade's job, the domain of a DSSSL or an XSL which
parses any arbitrary SGML blindly mapping tags to behaviours with no
concept of the meaning of the structure.  DocBook only prescribes the
structure of your document in terms of what tags can contain which
tags in which order, and which attributes are logically admissible for
each tag in its current context.

Clear as muddied water?

You will do much better if you consider DocBook to be "HTML on
steroids" than to try and fit the LaTeX or MsWORD mindset to DocBook.
Your output looks ugly?  It is supposed to be ugly: DocBook is not
Framemaker/XML.  sgmltools only includes the bare minimum tools to
'see' your DocBook texts; it's the DocBook DTD that is important and
whatever you do to visually present it is straying from the purpose.

There is a Zen saying which is probably apropos here: "When you hold
a bow, you don't use two arrows"  In this context, when you hold a
documentation tool, don't try to manage knowledge and graphic arts
at the same time because you will not hit either target.  An archer
who wants to hit a target uses only one arrow at a time. DocBook is
a one-arrow system.

When we do get GUIDocBooks, it will cause havoc: If your publisher
uses a different DSSSL from your Corel WP/9, the document will be
turned inside out and you will get angry because you had wrapped up
all your content thinking in terms of how it looked on your screen.
Instead, Norm Walsh is giving you the opportunity to structure your
thoughts on your subject matter, and only those thoughts. DocBook
thereby gives others the freedom to interpret your thought-structures
freely on a visual page to suit their purpose. 

    >> - Is there a simple way to convert DocBook to LaTeX and/or vice
    >> versa?  What about HTML?

See the above:  Can you convert coca cola to a hamburger and vice versa?
Both are junk food!  The two media are different at their core.

You could define a suite of LaTeX styles or a DVI viewer to wrap
DocBook tags around output text, but where would you get the data for
the attributes of those tags and how would you ensure the integrity of
the DocBook structure?  You could also write a DSSSL program to render
DocBook tags as \defs but where would you put the attributes and where
would you get information for visuals such as \vspace and \hfill?

That last issue is actually answered by the sgmltools: The included
stylesheets contain a very primative DSSSL to interpret a DocBook
structure and to render it on paper pages by specifying the layout
in LaTeX ...

    H> I'm not aware of translations to or from LaTeX.

Jade produces JadeTeX, a 'dialect' of LaTeX, but it does not look like
any LaTeX you have ever seen before.  Ditto for the HTML it produces.
These are generated for the convenience of producing DVI or web
outputs respectively and are not intended for human consumption.  You
could, however, write a DSSSL procedure to create more LaTeX-like
output, but there would be no point.
 
    >> - Are there any prepared idiot-proof packages for major Linux
    >> distributions with DocBook support

On my help page (http://www.teledyn.com/help/XML) I have listed the
defacto standard unofficial-but-fixed sgmltools distro that installed
very cleanly on my RH 6.0 and Mandrake 6.1 systems.

    H> DocBook is not intended for idiots (nor is LaTeX for that
    H> matter. But I managed to create a workable set of the sgmltools
    H> and some add-on stuff in RPM format.

DocBook and LaTeX are just technologies; as time goes on, just as
Framemaker and LyX removed the need for a novice to learn 200 LaTeX
commands just to be productive, we will see tools for DocBook.  

Today, DocBook is only just barely a standard.  The tools will come,
but I fear we will be stuck in a post-LaTeX and MSWORDpainter mindset:
Tools will be GUIDocBook abominations rather than the much more badly
needed RDBMS/XML systems required to really take advantage of the
attribute features of SGML documents.  This is another classic example
where consumer demand is dead wrong.

I remember quite clearly how HTML began.  In Cello, we had maybe 6
tags and we used them all poorly, but we grasped that great concept of
machine-independent presentation.  We began with H1 and drilled down
to H2, H3 and on to form an intelligent outline of our text. Images
occured where the text called for them --- pages may have been ugly,
but they were universally accessible, even to the blind. Along came
the browser-wars and all those GUIWebTools and TABLE lost its meaning.
Everyone wanted their columns to be X-pixels wide.  No one but me ever
uses MENU where it is appropriate because the GUI tools can't tell
MENU from UL.

(if you ask me, MINIPAGE should have been a valid HTML tag)

If you use CSS, you can create a website where MENU is quite distinct
from UL to lend visual meaning to the tagnames.  If you do this, you
will find you have a huge legacy of pages where many menus are coded
as un-ordered lists, and you will probably give up trying to fix them
all.  People like me kept screaming all through the 90's "Code HTML to
structure your thoughts, not to paint your browser screen!!!" but did
anyone listen to us?  No, you didn't did you.

DocBook is our revenge on you all! (HA HA HA) Spacer gifs, FONT
changes, and in-line per-tag CSS style directives are cement shoes
in the river of XML ;)  and it gives me great joy to count the many
webpages which will not be portable to coming age of PDAs.

-- 
Gary Lawrence Murphy <garym@linux.ca>: office voice/fax: 01 519 4222723
TCI - Business Innovations through Open Source : http://www.teledyn.com
Canadian Co-ordinators for Bynari International : http://ca.bynari.net/
Moderator, Linux Education Group: http://www.egroups.com/group/linux-ed


--  
To UNSUBSCRIBE, email to ldp-discuss-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org