On Sat, 7 Nov 1998 15:42:05 +0100 Chris Rowley <[log in to unmask]> wrote to LATEX-L : William F. Hammond wrote -- : : > : > SGML is all about fast staged processing. It is not very much about : > getting on to paper. : : That sounds like a reasonable summary of reality, if not theoretically : true. Well, maybe. But consider the fussy stuff about "look-ahead" involved in DTD construction. (That slur aside, it's mainly a pain for DTD construction, not for the use of SGML languages.) Qualification: Each individual SGML-to-SGML should be fast. Of course, if you compose them, the times add (or worse, depending on swapping). Parser output is a nice linear stream. My impression is that processors are NOT expected to seek but just to make one pass through it. (Then I believe that some processors construct the whole thing in memory as a tree.) I've been using Megginson's sgmlspl/sgmlspm (stabilized Dec. '95), which is event driven and, moreover, linear except for things that I choose to remember along the way (global variables for subsequent branching) and pieces of document (whole SGML elements) that I may push into temporary abeyance while descending subtrees. The biggest thing that I think sensible to so push is a paragraph. Of course, SGMLSPM has a cross-reference facility just as LaTeX does and if that is exercised by a document, then a complete second pass using an auxiliary file, as with LaTeX, is required. All one needs to do is write little functions in Perl. You don't need to be lisp-enabled. And some of those functions are very easy. When I'm ready to write an XML DTD that is nearly isomorphic to my SGML DTD for "article", the SGML-to-XML transformation that I use to make the type of *archival* document that I think the LANL preprint site should use is going to be *very* linear. : > There is a very lucrative and apparently profitable industry out there : > lurking behind closed doors. : : ????? Doing what exactly? Or are the doors too firmly closed to see? If you listen to the UseNet newsgroup "comp.text.sgml" long enough, you will see it. Yes, the doors are locked. In fact, just to get a copy of the definition of SGML from the ISO costs a substantial sum. (Better to buy Charles Goldfarb's _SGML Handbook_.) (But I expect that some young Ph.D.'s in math, rather than in computer science, will turn out to be leaders in this growing industry, and I find that pleasing to contemplate.) : > I suggest that individuals should think in terms of multiple SGML : > transformations as pre-processing for LaTeX. Some industrial strength : > publishers *may* want to think in terms of multiple SGML transformations : > as pre-processing to TeX directly. : : That is certainly an interesting question in general: staright to TeX : vs via LaTeX. : : Limited expereince suggests that some mixture may be needed; but : a lot depends on how and where the formatting is specified. Comments: 1. Megginson's sgmlspl/sgmlspm comes with docs that may be used to test the package. The two enclosed demo processors are: (a) DocBook to LaTeX (b) DocBook to HTML 2. I think that for most individuals and most academic departments processing to LaTeX to get to paper is the most sensible choice. 3. I am preparing demo processors from my DTD to (a) LaTeX and (b) HTML and eventually maybe to other things but I am much too lazy to code for straight TeX myself. It might be pleasant for those who have been accustomed to writing papers in plain TeX. 4. I would like to see someone who is fluent in Texinfo volunteer to code from my "article" dtd -- or something close to it -- to Texinfo. Along the way it should then become obvious how to give math full implementation there. Note in this regard, that GNU-emacs window displays are becoming progressively more useful in this regard. And as most vt100's are not actual hardware, those windows, which are fixed font displays with algorithmic "styling", could begin to admit a public standard for change of cursor position and more inter-line space in order to accommodate superscripts and subscripts, maybe also reasonable but crude fractions in displays. -- Bill