LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

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

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Mon, 3 Feb 2003 00:54:59 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <Pine.LNX.4.44.0302010348050.29347-100000@gilas>
Content-Type: text/plain; charset=us-ascii
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (58 lines)

 > > that's not the way it works in TeX, is it? at the time input encoding is
 > > translated to LICR we are before the decision for "text" or "math".  the
 > > naming conventions for the LICR objects are a bit dubious here as they often
 > > say "\text..." but that is the major goal for them, ie make the LICR objects
 > > work in text and with different font encodings. [...]
 > Sorry Frank, I don't understand the LaTeX internals completely, so
 > although I'm trying my best to understand your description, I can't
 > suggest any good solution.

all i was trying to say is the following (and i don't really think there _is_
a problem to solve)

 - the LICR in current latex is three sub parts:

   a) the majority of objects that only work in text (not math) and that have
   complex inner definitions, eg they change depending on the current text
   font encoding etc

   b) a noticable number of objects that only work in math  --- and as an aside
   are of a fairly simple and static definition each (type \mathchardef ...)

   c) a fairly limited set of objects that work both in text and math,
   primarily the visible ascii characters plus a few od symbols that have been
   set up this way.

The main part that was really tacked was a) when the system was built simply
because b) was and is and essentially will be static (it is a feature of
mathematics that symbols essentially do not change according to surrounding
conditions, eg making a formula uppercase just because it is in a running
heading is not really a good idea, etc ...)

with various limitations of TeX and size of memory etc extending c) was also
out of question in the early nineties.

nowadays this has changed and we can in fact provide a method (at least when
using e-TeX features) that allows us to make all LICR objects belong to type
c) in some sense

but since b) is nevertheless a static class of its own my approach is that all
externally incoming characters are mapped first to class a) and then have an
internal mapping that translates such objects to something in class b) if used
in math (ie via inpmath)

that would mean as far as unicode is concerned we map everything to a) ie the
wonderful names like \textgreater or \"a ... (what i said is that those names
are a bit of a pity, but this is something that is not really possible to
change but on the other hand not the end of the world either)

David's unicode file should then become much more straight forward.

has this explanation helped a bit?

good night