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 f12HD6710413 for ; Fri, 2 Feb 2001 18:13:06 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f12HDw708220 . for ; Fri, 2 Feb 2001 18:13:58 +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 f12HD5M29755 for ; Fri, 2 Feb 2001 18:13:05 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08D3B.685EBD00" 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 SAA24699 for ; Fri, 2 Feb 2001 18:13:04 +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 f12HD4M29751 for ; Fri, 2 Feb 2001 18:13:04 +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 <5.3D7BA38B@mail.listserv.gmd.de>; Fri, 2 Feb 2001 18:13:00 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 486341 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Fri, 2 Feb 2001 18:13:00 +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 SAA29939 for ; Fri, 2 Feb 2001 18:12:59 +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 SAA50400 for ; Fri, 2 Feb 2001 18:13:00 +0100 Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f12HCwu03968 for ; Fri, 2 Feb 2001 18:12:58 +0100 (MET) Received: from fell.open.ac.uk by venus.open.ac.uk via SMTP Local (Mailer 3.1) with ESMTP; Fri, 2 Feb 2001 17:12:56 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.9.3+Sun/8.9.1) id RAA14925; Fri, 2 Feb 2001 17:13:08 GMT In-Reply-To: <14969.12533.759505.917813@istrati.zdv.uni-mainz.de> References: <14968.34118.306909.315983@istrati.zdv.uni-mainz.de> <200101312200.XAA09346@bar.loria.fr> <14969.12533.759505.917813@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: VM 6.76 under Emacs 20.7.1 X-Authentication-Warning: fell.open.ac.uk: car2 set sender to car2@fell.open.ac.uk using -f Content-class: urn:content-classes:message Subject: Re: default inputenc/fontenc tight to language Date: Fri, 2 Feb 2001 18:13:08 +0100 Message-ID: <14970.60068.179603.570418@fell.open.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Chris Rowley" 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: 3697 This is a multi-part message in MIME format. ------_=_NextPart_001_01C08D3B.685EBD00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank wrote -- > > basically what you are saying is that moving text needs to keep = information > about its state with it, right? it fortunately doesn't need to keep > information about its input encoding since that got all normalised = into the > internal representation but unfortunately you need to keep information = about > the encoding used (or rather the encoding intended) > > a bit inconsistent that, isn't it? Not really: since input encoding really does mean just that. Once the text is `inside LaTeX' the input encoding is irrelevant: that is the beauty and strength of the LaTeX text character model. The confusion perhaps comes because part of the `inside of LaTeX' is various external files, .toc, .aux etc. These are unfortunately not internal to TeX, only to LaTeX. The whole concept of `moving argument' arises from this fundamental distinction between TeX and LaTeX: LaTeX, in this sense, is not just a TeX macro package. > but would it help if the language has a tie > to the [font] encoding? Whether the `intended font encoding' should be part of a moving argument leads to an important question. Note the word `intended': will it always be the case that text from a moving argument should be turned into glyphs using the same font = encoding as was used for the original text? > so we have to offer a choice, question is, is there a better way to = present > it? This is not really an answer but we can certainly provide a better interface than: > \usepackage[T1]{fontenc} ... no, I am not sure what it would be:-). chris ------_=_NextPart_001_01C08D3B.685EBD00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: default inputenc/fontenc tight to language

Frank wrote --

>
> basically what you are saying is that moving = text needs to keep information
> about its state with it, right? it fortunately = doesn't need to keep
> information about its input encoding since that = got all normalised into the
> internal representation but unfortunately you = need to keep information about
> the encoding used (or rather the encoding = intended)
>
> a bit inconsistent that, isn't it?

Not really: since input encoding really does mean just = that.

Once the text is `inside LaTeX' the input encoding is = irrelevant: that
is the beauty and strength of the LaTeX text = character model.

The confusion perhaps comes because part of the = `inside of LaTeX' is
various external files, .toc, .aux etc.  These = are unfortunately not
internal to TeX, only to LaTeX.  The whole = concept of `moving argument'
arises from this fundamental distinction between TeX = and LaTeX: LaTeX,
in this sense, is not just a TeX macro = package.

> but would it help if the language has a = tie
> to the [font] encoding?

Whether the `intended font encoding' should be part of = a moving
argument leads to an important question.

Note the word `intended': will it always be the case = that text from a
moving argument should be turned into glyphs using = the same font encoding
as was used for the original text?

> so we have to offer a choice, question is, is = there a better way to present
> it?

This is not really an answer but we can certainly = provide a better
interface than:

>  \usepackage[T1]{fontenc}

... no, I am not sure what it would be:-).


chris

------_=_NextPart_001_01C08D3B.685EBD00--