Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f12LZl711046 for ; Fri, 2 Feb 2001 22:35:47 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f12LaU709046 . for ; Fri, 2 Feb 2001 22:36:39 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f12LZcM19593 for ; Fri, 2 Feb 2001 22:35:38 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D60.1AA87B80" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id WAA14907 for ; Fri, 2 Feb 2001 22:35:37 +0100 (MET) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f12LZaM19588 for ; Fri, 2 Feb 2001 22:35:37 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <0.EA6BB57D@mail.listserv.gmd.de>; Fri, 2 Feb 2001 22:35:32 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486465 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 2 Feb 2001 22:35:32 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA03365 for ; Fri, 2 Feb 2001 22:35:31 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id WAA45366 for ; Fri, 2 Feb 2001 22:35:32 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f12LZVu25775 for ; Fri, 2 Feb 2001 22:35:31 +0100 (MET) Received: from [195.20.224.204] (helo=mrvdom00.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14Onrf-0002x6-00 for LATEX-L@urz.uni-heidelberg.de; Fri, 2 Feb 2001 22:35:31 +0100 Received: from manz-3e364887.pool.mediaways.net ([62.54.72.135] helo=istrati.zdv.uni-mainz.de) by mrvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14OnrK-0005Af-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Fri, 2 Feb 2001 22:35:11 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id WAA13415; Fri, 2 Feb 2001 22:33:39 +0100 In-Reply-To: References: <14968.6710.114015.220264@ux28.nets.de.eds.com> <200101292234.RAA14964@pluto.math.albany.edu> <14967.8829.903878.620595@istrati.zdv.uni-mainz.de> <200101310003.BAA02073@peano.cs.uni-dortmund.de> <14967.46479.253389.421142@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: inputenc -> text+math Date: Fri, 2 Feb 2001 22:33:39 +0100 Message-ID: <14971.10163.320991.33744@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3701 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08D60.1AA87B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 \@changed@cmd. 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 ------_=_NextPart_001_01C08D60.1AA87B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: inputenc -> text+math

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 \@changed@cmd. 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

------_=_NextPart_001_01C08D60.1AA87B80--