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 addressed: 1. Frontmatter/Bibliography 2. Definition of a portable subset of LaTeX. 3. Converters/Verification 4. Documentation 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 LaTeX file. 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 around math. - 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 learned. 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? Marcel 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 here. 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. Good idea. 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 interface. 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?