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 f16AFiH05638 for ; Tue, 6 Feb 2001 11:15:44 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f16AFhd04266 . for ; Tue, 6 Feb 2001 11:15:43 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09025.C3D3C800" 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 f16AFhM07348 for ; Tue, 6 Feb 2001 11:15:43 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA28142 for ; Tue, 6 Feb 2001 11:15:42 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f16AFg714298 for ; Tue, 6 Feb 2001 11:15:42 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <6.98399C69@mail.listserv.gmd.de>; Tue, 6 Feb 2001 11:15:37 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 487890 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Tue, 6 Feb 2001 11:15:38 +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 LAA28207 for ; Tue, 6 Feb 2001 11:15:36 +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 LAA44032 for ; Tue, 6 Feb 2001 11:15:37 +0100 Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f16AFbu29944 for ; Tue, 6 Feb 2001 11:15:37 +0100 (MET) Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.10.1/1.01.28121999) with ESMTP id f16AFa492364 for ; Tue, 6 Feb 2001 11:15:36 +0100 (CET) Received: from (ebrunet@localhost) by clipper.ens.fr (8.9.2/jb-1.1) Return-Path: User-Agent: Mutt/1.2i Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Tue, 6 Feb 2001 11:15:35 +0100 Message-ID: <20010206111535.A18424@clipper.ens.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Eric Brunet" 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: 3712 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09025.C3D3C800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable jbezos wrote: > Not at all. In latin1, character in the range 130--159 > are assigned to control characters (and hence I wouldn't say it like that: the 128--159 range is reserved so that if some document pass through a buggy programm that strips the eight bit, then the resulting document doesn't have any extra control characters = (in the 0--31 range) with some ``interesting'' properties. > they are not free), and Unix editors may > use them. No, they may not use it in a text file, as they are not text characters. On the other hand, all the text editors I know are perfectly able to handle binary files, or meaningless characters in a text file. If = someone runs any editor I know of on an ansinew file, he will some strange codes in lieu of the ansinew characters, and that would be it. Do you know of any editor which misbehaves ? And finally, the important think is that LaTeX would get the document right (which it would). > Further, a character in the ASCII > range (I have not the tables at hands, but IIRC is > right single quote) has been reassigned in ansinew. $ diff ansinew.def latin1.def| grep DeclareInputText < \DeclareInputText{130}{\quotesinglbase} < \DeclareInputText{131}{\textflorin} < \DeclareInputText{132}{\quotedblbase} < \DeclareInputText{133}{\dots} < \DeclareInputText{134}{\dag} < \DeclareInputText{135}{\ddag} < \DeclareInputText{136}{\^{}} < \DeclareInputText{137}{\textperthousand} < \DeclareInputText{138}{\v S} < \DeclareInputText{139}{\guilsinglleft} < \DeclareInputText{140}{\OE} < \DeclareInputText{145}{\textquoteleft} < \DeclareInputText{146}{\textquoteright} < \DeclareInputText{147}{\textquotedblleft} < \DeclareInputText{148}{\textquotedblright} < \DeclareInputText{149}{\textbullet} < \DeclareInputText{150}{\textendash} < \DeclareInputText{151}{\textemdash} < \DeclareInputText{152}{\~{}} < \DeclareInputText{153}{\texttrademark} < \DeclareInputText{154}{\v s} < \DeclareInputText{155}{\guilsinglright} < \DeclareInputText{156}{\oe} < \DeclareInputText{159}{\"Y} well, it doesn't show in the def file. IIRC, the story is that the ascii single quote character looks vertical in windows fonts, and so people prefer (incorrectly) to use the character 146 as an apostrophe. =C9ric ------_=_NextPart_001_01C09025.C3D3C800 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

jbezos wrote:
> Not at all. In latin1, character in the range = 130--159
> are assigned to control characters (and = hence

I wouldn't say it like that: the 128--159 range is = reserved so that if
some document pass through a buggy programm that = strips the eight bit,
then the resulting document doesn't have any extra = control characters (in
the 0--31 range) with some ``interesting'' = properties.
> they are not free), and Unix editors may
> use them.
No, they may not use it in a text file, as they are = not text characters.
On the other hand, all the text editors I know are = perfectly able to
handle binary files, or meaningless characters in a = text file. If someone
runs any editor I know of on an ansinew file, he will = some strange codes
in lieu of the ansinew characters, and that would be = it. Do you know of
any editor which misbehaves ? And finally, the = important think is that
LaTeX would get the document right (which it = would).

>          = Further, a character in the ASCII
> range (I have not the tables at hands, but IIRC = is
> right single quote) has been reassigned in = ansinew.

$ diff ansinew.def latin1.def| grep = DeclareInputText
< \DeclareInputText{130}{\quotesinglbase}
< \DeclareInputText{131}{\textflorin}
< \DeclareInputText{132}{\quotedblbase}
< \DeclareInputText{133}{\dots}
< \DeclareInputText{134}{\dag}
< \DeclareInputText{135}{\ddag}
< \DeclareInputText{136}{\^{}}
< \DeclareInputText{137}{\textperthousand}
< \DeclareInputText{138}{\v S}
< \DeclareInputText{139}{\guilsinglleft}
< \DeclareInputText{140}{\OE}
< \DeclareInputText{145}{\textquoteleft}
< \DeclareInputText{146}{\textquoteright}
< \DeclareInputText{147}{\textquotedblleft}
< = \DeclareInputText{148}{\textquotedblright}
< \DeclareInputText{149}{\textbullet}
< \DeclareInputText{150}{\textendash}
< \DeclareInputText{151}{\textemdash}
< \DeclareInputText{152}{\~{}}
< \DeclareInputText{153}{\texttrademark}
< \DeclareInputText{154}{\v s}
< \DeclareInputText{155}{\guilsinglright}
< \DeclareInputText{156}{\oe}
< \DeclareInputText{159}{\"Y}

well, it doesn't show in the def file. IIRC, the story = is that the ascii
single quote character looks vertical in windows = fonts, and so people
prefer (incorrectly) to use the character 146 as an = apostrophe.

=C9ric

------_=_NextPart_001_01C09025.C3D3C800--