## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: portable LaTeX

From:

Date:

Thu, 26 Nov 1998 13:14:18 -0500

Content-Type:

text/plain

Parts/Attachments:

 text/plain (176 lines)
 Sebastian writes: : my apologies. you ARE right about this. though I could and would argue : that people who spend 3 days tarting up the look of their grant : proposal don't deserve the grant :-} \ironic{Ummm... is Sebastian displeased with the current fad of PDF as an exchange format for grants? \quotestr{;-\} } : . . . : : > If someone now says why not SGML then: The advantage of LaTeX from the : > author's point of view is that it is a single platform for authoring, : > typesetting and document exchange (where, I believe, the problems can : ah, but see above. is it *so* much harder to type Now we come to what is, but for trivial transliteration, a matter of personal preference: : amsmath for this? ;-{ : :
Introduction
: $a+3$ : This is fun :
This could as well be: \documenttype{article} \title{} % Isn't title formally required by "article" in sebastian.dtd? \begin{document} \section{Introduction} $a + \sqrt{3}$ % or ... This is \emph{fun} \end{document} If I run this markup through my elisp, I get the following sgml:
Introduction
a + 3 fun

1. Introduction

a + SQRT{3} This is fun

AUTHOR  |  COMMENT

[Processed from GELLMU to HTML: Thu Nov 26 12:16:35 EST 1998] (Under "gellmu.dtd" there is a "surtitle" that is translated here for HTML as the HTML "title" with a default value in my sgml processor that is shown above; a GELLMU "title" is translated by this processor for HTML as the first "H1" header.) (Yes, there is a control of front matter unless you don't want it.) The main idea is that this type of markup is amenable to robust processing toward *any* target once an sgml processor for that target is created. Creating such a processor can be as easy as writing a Perl function for each tag; that might even be easier than writing a "style". Note that this approach is different from that of James Clark's "jade" which "centralizes" style for all "backends" using a DSSSL stylesheet for each document type. In the example above there is only a single document type "article" at hand. (The issue between my approach and that of "jade" *may* be how fussy an author or publisher wishes to be. (What may be good enough for "government work" *may* not be good enough for "elitist work".) Note that one of the possible outputs for jade is another sgml. It might make sense in my view to go part of the way with jade and then from there split off for different targets. Many options exist.) It would be easy to write a processor to convert the sgml to xml. (Some may be already out there, but I have no present need for that.) (Would someone like to write a processor for (a) plain TeX? (b) Texinfo? (c) text/x-yahoo-catalog?) For a processor to render sanely to MathML without much guessing (some guessing may be more reasonable than other guessing) some clues about notational meaning will need to be entered. Has anybody read my drafty draft on "mathexpr" (cf. "regexp") at the url http://www.albany.edu/~hammond/gellmu/notation ? ? ?                                    -- Bill