LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 8 Feb 2001 21:44:57 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (67 lines)
Michael wrote:
 >
 > The text/math ambiguity is a major problem for higher-level user
 > interfaces like Scientific Word. If the user enters \gamma + 1 without
 > first starting a math formula, then the proper way for the software to
 > write it is:
 >
 >   \textgamma \textplus 1
 >
 > instead of
 >
 >   $\gamma + 1$

but isn't this ambiguity already present anyway in TeX? and those interfaces
have to deal with it? E.g., if you write 1+2 without explicitly marking it as
a math formula you get a text string 1+2 not $1+2$ or to remind you about the
nice little article by Don Knuth  years back when he explained that he learned
he was misusing the fact that digits in text and math when using CM fonts look
the same so that his book Concrete math ended up looking horrible because
there  digits for text were coming from concrete roman while those in math
where coming from the euler fonts.

so i see no solution here for such systems other than forcing the user to
explicitly mark math as being math.

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.

my argument why i do not want of offer something like this as a default is
that:

 - it can't be explained which keys will work and which not (okay that is
   already difficult with claiming only visible ascii can be used in both by
   default, but the latter is far easier to explain)

 - we have no reliable solution unfortunately to resolve that \halign problem
   so far since Donald unfortunately has fail us :-) (so far that is)

the first point in my opinion is important enough to make a new set of
inputenc files all produce text only results.

As long as the second one remains unresolved i do have even qualms about
offering something like \DeclareInputTextAndMath for preamble or private
packages use since it would mean one would need to explain why in certain
situation one can get errors or worse (?) bad/incorrect typesetting results,
but i guess for the benefit of languages like Russian or Greek which really do
need such a feature it should probably be provided nevertheless.

However i still would hope one could find a way to get rid of it somehow.

 > Nevertheless it seems clear that it would be better to have a separate
 > hash table for math commands and text commands. So \gamma could have one
 > definition in math and another one in text without the constant use of
 > \relax \ifmmode a\else b\fi. This of course is not possible in TeX 3.x;
 > perhaps in NTS or e-TeX or Omega.

but that would not solve the problem either (though I agree it would perhaps
be a good extension) since the problem with the \halign really is the timing:
you see the \"a under the assumption that you are parsing for text mode so you
expand whatever the internal form expands to, eg \OT1-cmd \"\OT1\", then you
expand \OT1-cmd which i wont bother to write down here :-) and by the time you
reach, say \accent and trigger the template's u-part your original \" is long
gone; so if now the u-part puts a $ in front you are too late.

frank

ATOM RSS1 RSS2