## 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 >>]

 Subject: Re: inputenc -> text+math From: Frank Mittelbach <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Fri, 2 Feb 2001 22:33:39 +0100 Content-Type: text/plain Parts/Attachments: text/plain (68 lines)
Lars wrote:

> >
> >will have broken text inside, wouldn't it? or do i overlook something?
>
> There is an \ifmmode in \@inmathwarn, which appears in both \@current@cmd
> and \@[log in to unmask] If that isn't fully expandable all text command might be
> affected by broken ligatures and kerns.

yes this is why I claim it is wrong. However, thinking about it: for cyrillic
this isn't a problem (most likely) since the internal representation of text
is then consisting nearly exclusively of font encoding specific commands so
the first glyph would already reset the \ifmmode setting and thus no ligatures
get broken.

the problem only appears in languages which contain a good deal of ascii so
that the first font encoding specific command might appear in the middle of a
word.

> Simply fiddling with the definition of \ifmmode isn't sufficient for taking
> care of all related problems. The small document
>
> \documentclass{article}
> \usepackage{array}
> \usepackage[T1]{fontenc}
>
> \begin{document}
>
> \begin{tabular}{>{\fontencoding{OT1}\selectfont}l}

who would do such a thing? :-)

actually more or less the same sample document was shown to me last week.

yes you can't change font encodings safely inside array's >{...} right now.

> However, I noticed that a \noexpand\empty will stop the alignment mechanism
> from looking any further for an \omit, so it isn't necessary to insert an
> actual command to prevent it from scanning any further. Unfortunately a
> \noexpand\empty also breaks ligatures (and most likely kerning as well; I
> haven't checked) so simply inserting that into e.g. \IeC and \T1-cmd and
> friends isn't the solution either.

\noexpand\@empty is a somewhat expensive way to say \relax actually :-)

> What I suspect is the right solution is to have \protect set to
> \@unexpandable@protect when scanning for \omit and have it reset to
> \@typeset@protect in the column template---then the robustness mechanisms
> for normal robust commands, text commands, and in the \IeC command
> respectively would take care of sorting things out. I doubt this can be
> done by patching the \halign primitive, but it could be built into e.g. the
> array package.

yes, that would solve the problem i'm pretty sure of it but as i said in my
earlier mail this really doesn't help because it would then only work in array
but not in, any contributed package that uses \halign (this is why Vladimir
tries to patch \halign).

perhaps one should investigate combining your solution (change of protect)
with a patch to \halign after all, eg via a clever use of \everycr and the
like.

where is the solution Donald? this should be the kind of problem you like to
tackle, or not?

frank