LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
William F Hammond <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Sat, 13 Feb 2010 13:59:01 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (54 lines)
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

ATOM RSS1 RSS2