Re: New software coming soon

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

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