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

#### View:

 Message: [ First | Previous | Next | Last ] By Topic: [ First | Previous | Next | Last ] By Author: [ First | Previous | Next | Last ] Font: Proportional Font

Subject:

Re: inputenc -> text+math

From:

Date:

Fri, 2 Feb 2001 22:33:39 +0100

Content-Type:

text/plain

Parts/Attachments:

 text/plain (67 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