So would anybody be interested seriously set up a portable LaTeX
project? For a start, I can see the following areas that need to be
2. Definition of a portable subset of LaTeX.
I think the frontmatter/bibliography stuff we have discussed enough,
maybe just one more idea (although I have to admit complete ignorance
here as so far I never got round to using bibtex): Can these two
elements be made work in exactly the same way? I.e., to use the same
user interface and tools for both? In particular, this would mean
that the frontmatter can be optionally (!) supplied from a frontmatter
database (from which the author could directly quote in later papers);
similarly, the bibliography could optionally be marked up (like the
frontmatter today) within the document on the same level of
abstraction as the bibliography database.
Part 2 has been discussed quite extensively... probably needs some
summarizing and expert opinions.
For area 3, one would initially need at least one reference
implementation of a LaTeX to *ML converter were one must make sure
that it supports a complete portable LaTeX standard which allows
serious scientific publishing without unnecessary restrictions. (Would
the Elsevier converter come close to this description?) Moreover, a
(TeX based) LaTeX package for verifying that the portability of a
The documentation part is obvious. Maybe here the "Bazaar" style of
development could be use most effectively, if a suitable WWW based
documentation server could be set up.
Why is this important? I think from all the discussion it is apparent
that there is no alternative to LaTeX as an authoring language (as
opposed to data exchange, archival, or symbolic computing language).
Further, I yet have to see a WYSIWYG tool which matches the efficiency
and power of LaTeX. Two reasons:
- The LaTeX input syntax (or whatever we take that for) is a
reasonable compromise between consistency and readability. I think
for all what I have seen, *ML tends more towards consistency and
less towards readability (which I guess is what they were designed
for). Having authored quite a bit of raw HTML (please no flames...)
I find the angle brackets and forward slashes disturbing, especially
- LaTeX is hackable. While this is certainly opposed to the goals of a
portable LaTeX standard, it is a tremendous advantage for authors as
"portable" and "non-portable" writing projects (where visual mark-up
in slides, CVs, invitation cards, or special effects which are
sometimes necessary) can be done with the same system; code can be
exchanged with minimal alterations between "portable" and
"non-portable" documents, and only one markup language need be
I believe a lot of resistance to a pure *ML solution comes from the
fear for loss of hackability.
Do people feel that such an approach is useful and has a sufficient
chance of success? If so, would anybody actually do some work? I am
fairly time constrained, but could imagine doing something concrete
about topics (1) and (4)---not before January though. Or shall we do
business as usual?
PS.: Some misc. comments to remarks on the list:
Hans Aberg wrote:
> EBNF like other computer languages. The problem is that there is no
> way within TeX to ensure that authors use that syntax. Further, TeX
> integrates authoring and typesetting in a way, making the task even
> more difficult.
I don't think it is really a problem. At least I think I have a
pretty good idea about what's LaTeX and what isn't. Things get much
more difficult to keep functionality portable, and this is what needs
to be discussed in detail.
"William F. Hammond" wrote:
> What you describe is the conscious goal of my GELLMU, which is found at
> http://math.albany.edu/~hammond/gellmu/ ,
I looked at your pages, but I cannot see the advantage of "LaTeX-like"
vs. "subset of TeX/LaTeX". When a document is authored, it is typeset
many many times, while it is converted to other formats very few
times. So it seems counterintuitive to require preprocessing for the
most frequently occurring task. Moreover, a large percentage of
existing LaTeX documents are portable or could be make portable by
trivial changes, so this base of documents would be lost for no
apparent gain. Last, the loss of hackability problem also applies
Roozbeh Pournader wrote:
> What about considering every core LaTeX feature and rethink about
> moving them to tools or taking them from there? E.g., many agree
> that picture should go there (since it's used less and less), and
> array should come from there.
Sebastian Rahtz wrote:
> i'm slightly bemused to hear that mathematicians now require special
> _hypertext_ as well as everything else. but I'd point out that a
> link embedded in a PDF document should be able to be expressed in
> XPointer syntax perfectly well, which helps a little. I'd agree that
> internally the PDF model is simplistic - but then who *has*
> implemented anything better in mainstream software?
Personally I am quite happy if I can find a document that I need on
the net. Whether it comes in dvi, postscript, PDF, or LaTeX2HTML (with
math as gif) is really secondary. Anyway, the problems of optimizing
web browsing should not be our concern, it's more important to
implement the infrastructure to make LaTeX documents convertible into
potential browser formats or other formats that exists or may come
along in the future by providing a consistent and well-defined
Sebastian Rahtz wrote:
> by which we see why LaTeX is unpopular in production workflows. that
> translates to "10% failure"
So this should be addressed by a portable LaTeX standard.
Sebastian Rahtz wrote:
> my (admittedly naive) view is that presentation MathML is like plain
> TeX maths, ie it provides building blocks for putting practically any
> math on the page. real users put a layer on top (macros), to let them
> write commands which have semantic meaning for them.
> if you accept this, then the XML/MathML world is no different. make up
> a new language, using XML syntax, to say whatever you want
> <foo n="3">x<bar>y</bar></foo>
> (forget the verbose syntax for now), and then provide the XSL
> transformation script which maps that to presentational MathML. within
> your own research group, write software which groks <foo> directly.
Would this not create similar portability/conversion/parsing problems
that we have with TeX now if this were sufficiently powerful?