Roozbeh, > > 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 frank