- From: William F. Hammond <hammond@csc.albany.edu>
- Date: Tue, 18 Aug 1998 10:47:44 -0400 (EDT)
- To: kcc@miem.edu.ru
- Cc: www-math@w3.org
Kostya -- > Does any one have some _ready_to_use_ translation tool from TeX/LaTeX > to MathML? I asked nearly the same question here about three months ago, and I did not find what I wanted, which I think is close to what you want. So I have thought about the whole issue of authoring languages. One conclusion is that authoring languages are somewhat personal, and different individuals have different tastes. A related observation is that, just as it makes sense for an individual always to use the same editor (on whatever platform) and the same mailer (on whatever platform), it also makes sense for that individual to be able to use the same document authoring language regardless of the choice of the set of ultimate presentation formats. I think it very unlikely that a sane translation tool from either TeX or LaTeX to "HTML-extended-by-MathML" or "HTML-with-MathML-<object>-tags" exists. You would *almost* be better off with the kind of "text/plain" that John Baez uses to author "This Week's Review..." in the Usenet newsgroup "sci.math.research". Successive approximations are another matter, and the more you work, the more you will get. However, for such a scheme to be worthwhile there needs to be a disciplined organization to it. One ready-to-use source of disciplined organization is SGML. I am not speaking of low-potential-energy, close to presentation, SGML languages like HTML or MathML, but high-potential-energy SGML languages that are close to, say, LaTeX input source without some things that belong elsewhere such as "\newcommand", which belongs in personal macro pre-processing, and "\setlength", which belongs in "style". I think that it is reasonable to view any good nicely-structured markup, e.g., systematically prepared LaTeX, even systematically prepared TeX, as some kind of "categorical" limit of SGML document types. (For the moment I am not sure just what the "category" is formally.) This means that I suspect that there is no complete SGML document type definition for such languages, except there may very well nearly be one for Texinfo (the markup language of the Gnu Documentation System). For individual authors and individual departments it should be possible to develop document types that can, after simple transliteration, be processed by SGML tools. If so, there is a lot to think about. One can go a very long way with "nsgmls" (James Clark, http://www.clark.com/) piped to "sgmlspl" (David Megginson, http://home.sprynet.com/sprynet/dmeggins/), the first in platform independent "C" and the second in Perl. They have done all of the hard work. You would need to (1) provide an SGML document type (and I find DTD's nasty to debug), (2) make a transliterator from your favorite language to your SGML document type, and then (3) ask your friends to help you write Perl codelets to handle each of the tags that you actually use. "sgmlspl" is event driven, and the codelets for "sgmlspl" can be arbitrary Perl functions. You can do more with "sgmlspl" than with stylesheet processing. (I view these tools as reasonable only for authoring platforms, whereas stylesheet processing may be done elsewhere.) I've been playing with this since June 20 or so, and I'm quite impressed. "nsgmls" appears to have an ironclad reputation. The final release of "sgmlspl" was December 1995, and I've had no problems with it although occasionally my code is vexing to debug. (It would be easier if the tag codelets could be written in elisp.) If you want to see some of what I have so far, visit my web site here. At this time I have no code toward MathML. In the near future I will be coding for presentation targets that my students can read with what they have at home. So in my HTML target the math will be somewhat TeX-like. (I have never thought it good to use non-scalable images.) Anyone is free to hack on the code for the HTML target in order to incorporate MathML. I should add that my ideas for putting math in the high potential energy SGML are not all implemented, and my DTD and codelet packages are all very much (1) didactic and (2) in flux. To this point I have NOT had to rip stuff out in any serious way in order to add features. So I am reasonably confident about "sgmlspl". When MathML becomes reasonable for my students, it will be easy to put it up by revising my codelets rather than by revising my document source. -- Bill Hammond
Received on Tuesday, 18 August 1998 10:47:24 UTC