From: G. Milde <milde@us...>  20080515 10:00:40

On 14.05.08, David Goodger wrote: > On Wed, May 14, 2008 at 1:38 PM, Alan Isaac <aisaac@...> wrote: > I don't think that a Writer should handle unrecognized formats. > Recognizing formats and dealing with input is the job of a Parser or > Reader. A Writer's job is to convert a standard doctree to the output > format. > Yes, I realize that this is dealing with a distinct data format, so > the model may break down. But this is something to keep in mind. We should care to differentiate between *input*, *internal*, and *output* format. The basic question for inclusion of a mathdirective is "How should the standard doctree store the content of a math node?" I. e. which *internal* format should docutils use. The set of supported input and output formats can be extended later without change to the doctree specification. IMO, the main candidates for the *internal* data format are: LaTeX best graphical representation, relatively simply to type in directly, widely supported and established in the scientific community. MathML modern dataexchange format, standardised, "the future", hard to type in by hand. Unfortunately, conversion between them is not always lossless, so it is desirable to keep input data that is in one of them in this format if the *output* data requires the same. > Math processing [...] should be handled [...] in a Transform. Even if > the output depends on the type of Writer, a Transform is the way to go. IMO, the Transform should convert the *input* format into the *internal* format (the one required by the current writer or both), normalising the doctree. Jens' latexmath provides the code for a LaTeX>MathML Transform, searching for a suitable MathMLLaTeX converter is the next important step. > By the time the Writer sees it, the math should be just a blob to > insert into the output stream. In the most basic cases, yes. But generally a writer will convert the *internal* format of the standard doctree to the *output* format. * the html+mathml writer just inserts the Math ML, * the latex writer inserts LaTeX code. However, some html writer variants (or options) would care for older browsers not understanding MathML * "html+pngmath" would produce graphical representations of the formulae from the LaTeX data (a la latex2html), * "html+htmlmath" would convert the MathML to a HTML+CSS substitution, * "htmljsmath" would write HTML+javascript for the jsmath extension... Other writers are feasible as well, e.g. * a "unicode" writer could convert the math node content to a textual representation using the Unicode chars for math symbols. (Unicode defines "all possible" mathematical symbols, using a fixedwidth font, even large symbols (spanning multiple lines) can be constructed.) Günter 