Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Jun 1996 19:59:08 -0500 (EST)
From:      John Fieber <jfieber@indiana.edu>
To:        Chuck Robey <chuckr@Glue.umd.edu>
Cc:        Greg Lehey <grog@lemis.de>, FreeBSD Documenters <doc@freebsd.org>
Subject:   Re: How do I write this SGML stuff?
Message-ID:  <Pine.NEB.3.93.960608193213.303U-100000@Fieber-John.campusview.indiana.edu>
In-Reply-To: <Pine.OSF.3.91.960608132901.32620B-100000@ginger.eng.umd.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Jun 1996, Chuck Robey wrote:

> No, we aren't wed to LaTeX, we're discussing sgml tools that convert to 
> troff (which I like too) and to html, LaTeX, etc.  We don't write our 
> docs in troff, we're doing it in some kinda sgml, and I guess the 
> discussion is about the tools we're using to get from sgml to (whatever).

And SGML has *nothing* to do with formatting.  It is about
marking up a documents content based on the nature of that
content on the premise that a much broader range of uses can be
achieved from a document marked up in that manner.  The most
important use for us here and now is rendering that document as
(a) a set of HTML pages, (b) an ascii document and (c) a typeset
document.  For the latter two, groff will be the tool of choice.
Currently groff is used for ascii, with less than stunning
results, and LaTeX is used for typsetting, which offers good
results but is a hassle because TeX is a port, while groff is
standard equipment. 

The other issue at hand is the desire to free ourselves from the
limitations of the linuxdoc DTD whose markup models is based on
LaTeX which ultimately undermines the benefits of using SGML.
Docbook looks to be a likely choice as the successor, being a DTD
designed by and for the software technical writers.  Such a move
necessitates a more powerful document manipulation tool than we
currently have because there is a wider gulf between the
descriptive markup that the DTD provides and the procedural
markup used to drive a formatter.

> view of John Clark's sgml tools.  I'm very unhappy with our present 
          ^^^^- James actually
> conversion tools from sgml to whatever, because they are one pass things, 
> have limited intelligence and capability, and were chiefly made to 
> convert from sgml to LaTeX.

And the only reason conversion to html works at all is because of
a second and third pass implemented in perl and even that is too
limiting.  

What instant does is read the document into a tree (any
conforming sgml document can be represented as a tree) which you
can navigate as you please during processing; "passes" is no
longer relevant terminology.  For example, if I hit a cross
reference, I can easily search the tree for the other end of the
link, scan up the tree until I find an appropriate sectioning
node, eg, <SECT>, grab the text out of the <HEADING> tag that
follows and insert it where I started.  A big improvement for
HTML output is being able to look ahead at the sectioning and
make more intelligent decisions about how to break up the the
document into smaller files.  The current method provides a
terrible mix, with many pages of only a paragraph or so (sections
that should be presented together) and others that are terribly
long (sections that must be split).


-john

== jfieber@indiana.edu ===========================================
== http://fallout.campusview.indiana.edu/~jfieber ================




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.93.960608193213.303U-100000>