Date: Fri, 22 Aug 1997 20:50:03 -0400 (EDT) 
From: Eitan Gurari <[email protected]> 
To: ... 
Subject: LaTeX (TeX?) to MathML converter 
 
 
The way that I understand it, the current proposal is to build a new 
engine for math formulas, modeled after the one used by TeX.  It seems 
to me that, with a little change of a direction, we might have here a 
golden opportunity to get much more than just a converter to MathML 
from a subset of (La)TeX. 
 
The alternative approach I have in mind consists of a minor 
modification to the TeX engine, for optionally seeding dvi files with 
\special-hints.  Specifically, in standard mode, TeX will output the 
standard dvi output, and ignore the modifications made to its 
engine. On the other hand, in ‘special’ mode (activated, e.g., by a 
switch in a command line), TeX will output self-created \special 
instructions into the dvi code. 
 
The specials will mark strategic points in the dvi code, with the 
objective of acting as hints to drivers which process the dvi code. 
In the case of formulas, the hints will identify the boundaries of the 
formulas, the subscripts and superscripts, and other entities of 
significance. In the case of halign and valign tables, the specials 
will be placed around the tables, around the rows, around the entries, 
and at omitted boundaries. Other locations of possible interest might 
be page, paragraph, and line breaks.  Hence, creating sgml-oriented 
tagging, with desirable interpretations provided by dvi drivers. 
 
The following are the main advantages that I can see for the 
alternative approach. 
 
1. Compatibility.  The marking by the special hints will work with 
   all TeX-based source documents, no matter what instructions and 
   style files they employ (including the rich collection of amstex 
   and amslatex documents). 
 
2. Flexibility. Alternative sgml tags to MathML will be possible, 
   including tags customized by users with realizations in 
   style sheets.  Non-hypertext applications might also find uses for 
   structural hints emitted by TeX. 
 
3. Usability. The original proposal is oriented toward 
   latex2html like systems that try to emulate, only with partial 
   success, the behavior of TeX. The alternative proposal will serve 
   such systems, as well as more recent systems that rely on the 
   native engine of TeX to do the job (e.g., vtex, tex4ht--my system). 
 
   In fact, latex2html will need to do only a minor adjustment 
   to its current implementation.  Instead of placing <IMG> pointers to 
   gif’s created externally for the figures, it will import 
   the MathML code created externally. 
 
4. Portability.  The same as for TeX. 
 
5. Effort.  It seems to me that the effort needed to modify the 
   TeX program should be minimal, for someone who is familiar with 
   the program (not me).  I guess the following statement 
   from the TeX program is applicable here. 
 
      1340. Extensions.   The program above includes a bunch of "hooks" that 
      allow further capabilities to be added without upsetting TeX’s basic 
      structure. Most of these hooks are concerned with "whatsit" nodes, 
      which are intended to be used for special purposes; whenever a new 
      extension to TeX involves a new kind of whatsit node, a corresponding 
      change needs to be made to the routines below that deal with such 
      nodes, but it will usually be unnecessary to make many changes to the 
      other parts of this program. 
 
      In order to demonstrate how extensions can be made, we shall treat 
      ‘\write’, ‘\openout’, ‘\closeout’, ‘\immediate’, ‘\special’, and 
 
   Extracting the code from the dvi files should be a straightforward 
   task for a driver, when the special hints are present. 
 
   On the other hand, the following quote from the TeX program might 
   also be of interest, if the original proposal intends to include tables. 
 
      768. Alignment.   It’s sort of a miracle whenever \halign and \valign 
      work, because they cut across so many of the control structures of 
      TeX. 
 
6. Stability.  The core of the TeX engine is a frozen component, probably 
   untouched even by its recent extensions (etex, pdftex, ...). Hence, a 
   well thought set of \special-hints will provide a stable base for 
   different drivers to play with. 
 
Thanks for your attention, -eitan 
 
 
> Consultant/Programmer sought to develop an LaTeX to MathML converter: 
> 
<snip> 
> 
> The MathML specificaion was written with an eye toward the ability to 
> convert other mathematical data formats into MathML.  Translators that 
> can convert mathematical documents utilizing TeX markup will be 
> especially useful due to the large quantity of TeX documents that the 
> research mathematics community has authored over the past decade. 
> 
> The AMS, the Geometry Center, and SIAM intend to collaborate to 
> support the development of a general purpose LaTeX to MathML 
> translator, using the popular public-domain LaTeX2HTML utility as 
> model.  LaTeX2HTML converts a LaTeX document into an HTML document in 
> two general passes.  First, LaTeX document structures are converted 
> into HTML (e.g. \section to <H1>) and second, each piece of LaTeX math 
> is converted into a GIF graphic and inserted into the HTML document 
> with an <IMG> command. 
> 
> We are seeking a consultant/programmer skilled in both TeX and Perl 
> (LaTeX2HTML is written in Perl) to adapt LaTeX2HTML to create MathML 
> code for each piece of LaTeX math rather than producing GIF graphics. 
> Since the end result must be completely compatible with LaTeX, we are 
> envisioning the job in terms of modifying TeX to convert its internal 
> math list structures into MathML.  However, the exact methodology 
> employed would be at the discretion of the consultant. 
> 
<snip>