## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

        Frank Mittelbach <[log in to unmask]> writes:

>  > > that's for the case where \"a is precisely *not* executing an
>  > > \accent but is actually a glyph in the current font
>  >
>  > But that is the only case you have to handle!  \accent combinations
>  > don't have the right kerning anyway, so just stick \relax before
>  > the \accent.
>
> you both are right and i was wrong (for the case of
> accents). however you would have to identify that \"a is a glyph
> first, even more, you would need to do the right thing concerning
> any text character eg some are fetched from a different encoding so
> all that would be very messy indeed
>
>  > The (killer) problem I see has already been alluded to: The inputenc
>  > characters are already active, so you have to have a single definition
>  > that works for both the initial expansion of the input text and as the
>  > math-active character, without recursion.
>  >
>  > David's usage of "ä" is probably part of the "illegal notation", but if
>  > I may either clarify or fix:
>  >
>  > Definition to convert from LICR to glyph:
>  >
>  > \def{\"a}{\ifmmode \relax % make sure we are in math mode to stay
>  >           \ifmmode \ddot a%
>  >           \else \string ä\fi
>  >           \else \string ä\fi}
>
> sorry, perhaps i'm still dumb from my cold or else dumb anyway, but
> i don't get you here. what is this supposed to tell me?
>
> one of the problem is that pressing key ä (umlaut-a) on the keyboard
> maps to \"a alright in the LICR but that is not equiv to doing
>
>  \string ä
>
> for typesetting --- the slot to use varies from encoding to
> encoding. so if i interpret your definition above correctly then you
> end up with exactly typesetting \char ä always for \"a ... or what?

Certainly.  That is why I said that this would only work where input
and font encoding matched.  Then you said it would not work at all,
then Donald explained why it would, and now you have forgotten already
that I said it would only work with matching inputenc and fontenc.
That is why I said that it would be nice to have the active
mathcharcode thingie have an option mapping to a different active
character.  Not sure that would solve all problems, and it would
probably be much saner to use \protected as explained instead of
trying to fudge another extension into TeX.

that you go through the last few mails of this exchange again to get
the context again.  The above was only mentioned as an expedient for
a special case, not as an actual implementation proposal.

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
`