References: <17580.1265876941@cl.cam.ac.uk>
            <OFC062270E.60C633A3-ON802576C7.0080A6E5-802576C7.0080A6F8@mcs-notes1.open.ac.uk>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.4 (usg-unix-v)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID:  <i7eikp6jyi.fsf@hilbert.math.albany.edu>
Date:         Sat, 13 Feb 2010 13:59:01 -0500
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@listserv.uni-heidelberg.de>
Sender: Mailing list for the LaTeX3 project <LATEX-L@listserv.uni-heidelberg.de>
From: William F Hammond <hammond@CSC.ALBANY.EDU>
Subject: Re: LaTeX3 8-bit only?
To: LATEX-L@listserv.uni-heidelberg.de
In-Reply-To:  <OFC062270E.60C633A3-ON802576C7.0080A6E5-802576C7.0080A6F8@mcs-notes1.open.ac.uk> (Chris Rowley's message
              of "Thu, 11 Feb 2010 23:25:13 +0000")
Precedence: list
Status: R

Chris Rowley writes:

> Well I am filing away all these predictions, especially those of
> Nostraschroeder.

If I may refer to Chris' talk on "TeX-free LaTeX" at TUG 2009 in South
Bend, http://river-valley.tv/tex-free-latex-an-overview/, all four of
GELLMU, LaTeXml, Plastex, and Tralics are characterized by early stage
parsing to some form of XML and going from there to various outputs.
Moreover, Texinfo, the language of The GNU Documentation System, which
has been formalized as an XML document type for nearly a decade now,
operates in a similar way.  Furthermore, I think that tex4ht would be
improved by factoring all of its various output formattings through
initial parsing (using its dvi-loading technique) to an XML document
type that is closely tuned to LaTeX and translating to the various
outputs from there.

It has long seemed clear to me, going back to the discussion thread in
1998 where I jumped in, that, beyond continued support for traditional
print-only typesetting, the LaTeX Project needs to formally define(*)
LaTeX, the markup language.  (Well, maybe a series of related
languages.)  This will amount to introducing one or more author-level
XML document types with Project sponsorship.  Doesn't the confluence
in design of the four horsemen bolsters this viewpoint?

If that is done competently, then pipelines of translations become the
game.  At the end of some of these pipelines there can translation to
the traditional typesetting language, geared to whatever engine, but,
as well, translation to Context, as Martin suggested.  I find it very
unclear what might work best.  In the end it may well amount to the
question of who spends how much time on what.

Meanwhile, I think the LaTeX Project needs to get more serious about
non-print formattings.  For example, Tim Arnold at TUG 2009,
http://river-valley.tv/getting-started-with-plastex/,
laments the quality of XHTML+MathML display in web browsers.
(Actually, I think, for example, Firefox 3 with the stix betas is
fine, and I find no reason for complaint about Design Science's
MathPlayer apart from the limitations of plugin technology.)

Two new things to be aware of:

1.  Mathjax, a collaboration between Davide Cervone, author of jsmath,
and Design Science should soon provide a way for _any_ full service web
browser to render (a) XHTML+MathML as well as (b) HTML with TeX-like
math (à la jsmath) without making demands on the end user.

2.  There is a project to provide native handling of MathML in
"webkit" browsers, e.g., Safari and Google Chrome.

                                    -- Bill

(*) Sorry for the split infinitive