LISTSERV mailing list manager LISTSERV 16.0

Help for LATEX-L Archives

LATEX-L Archives

LATEX-L Archives

Error - template BODY-GLOBAL-NOTABBODY-UNENDED not found

A configuration error was detected in the CGI script; the BODY-GLOBAL-NOTABBODY-UNENDED template could not be found.
Subject: Re: inputenc text (and/or math)
From: Michael John Downes <[log in to unmask]>
Reply-To:Mailing list for the LaTeX3 project <[log in to unmask]>
Date:Fri, 9 Feb 2001 09:59:48 -0500

Frank Mittelbach <[log in to unmask]> writes: > but isn't this ambiguity already present anyway in TeX? and those interfaces > have to deal with it? > so from that perspective I see no argument against having the possibility to > use keys generating 8bit characters to be used in text and math producing > different glyphs. I didn't explain clearly. What we have now is that (a) For people with GUI interface like Scientific Word, the software has to deal with the ambiguity as best it can. (b) For people with non-GUI interface like vi, writing a Greek letter (for example) outside of math leads to a TeX error at run-time. If the 8-bit latin-1 characters that look like \times and \mu are made to work equally well in text as in math, then doesn't it seem likely that the people in case (b) are going to make more markup errors (writing \mu etc as a text symbol when it should be wrapped in a math formula) because there is nothing to bring it to their attention (other than reading the documentation :-) ? In other words currently it is easy for people in case (a) to make those markup errors, and the proposal under discussion would extend this so that it is easier for all users. It's not clear that this is progress. :-) I guess I don't have a solution, I am just reflecting on the idea that the restriction of mathchardef'd symbols to math mode was intended (I think) by Knuth to bring markup mistakes to the user's attention. Instead of an error, he could have arranged that \gamma triggers start-math, just as letter X triggers a switch from vmode to hmode. To be sure, because we have \ensuremath it is already possible for people who read the documentation to inconsistently omit math markup all over the place anyway. But it has always seemed to me that it might be better to tell the editor about the "ensuremath" objects and have the editor insert $ $ automatically when necessary rather than have LaTeX do it by using \ensuremath. If anyone is not sufficiently confused enough yet I invite them to consider how LaTeX might better handle "<" and ">" when someone uses them in text. In OT1 encoding LaTeX silently gives the wrong symbol, in T1 you get the math less and greater (when what the user wanted was probably langle rangle or else guillemets).