Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Feb 2003 15:05:23 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h13E5I6C018265 for ; Mon, 3 Feb 2003 15:05:21 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h13DvgXM022379; Mon, 3 Feb 2003 14:57:42 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CB8D.4B109380" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h133iQKB031075; Mon, 3 Feb 2003 14:49:14 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7241 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 3 Feb 2003 14:49:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h13DnEPw003025 for ; Mon, 3 Feb 2003 14:49:14 +0100 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h13Durtt014053 for ; Mon, 3 Feb 2003 14:56:53 +0100 (MET) Received: from [130.239.20.144] (mac144.math.umu.se [130.239.20.144]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id OAA21339 for ; Mon, 3 Feb 2003 14:52:31 +0100 (CET) In-Reply-To: <200302030932.JAA05953@penguin.nag.co.uk> References: <15933.43565.751843.247809@istrati.mittelbach-online.de> (message from Frank Mittelbach on Mon, 3 Feb 2003 00:30:53 +0100) <200301311603.QAA22049@penguin.nag.co.uk> <15933.43565.751843.247809@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 03 Feb 2003 14:05:24.0540 (UTC) FILETIME=[4BFB8FC0:01C2CB8D] X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h13DnEPw003026 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -0.8 () IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 Content-class: urn:content-classes:message Subject: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Date: Mon, 3 Feb 2003 14:58:25 +0100 Message-ID: A X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Thread-Index: AcLLjUwgff4o9jB1SBuKRD2Wx4g62Q== From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4527 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CB8D.4B109380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 10.32 +0100 2003-02-03, David Carlisle wrote: > >> Ideally I think that I'd like the latex field to consistently have >> a command that could be used as latex's internal encoding independent >> command, together with some latex packages to define any additional >> commands needed, so you could switch at the latex level between >> displaying the glyph, or faking it with TeX constructs or making a >> missing-glyph marker, depending on the fonts available. > >That's just another way of saying the latex field should have LICR >commands. For Latex use only it would be just as easy to define the >mappings directly in the latex package files but having them in that = XML >would I think help translators from XML (especially MathML) to TeX to >come up with consistent mappings, as all the MathML entities and >character documentation is derived from there. IMO some definition of the LICR commands which is distinct from the code = in the LaTeX packages is needed, since the current state of things is = rather implicit. It is possible to see that something works in all cases one = can think of, but it is not possible to see whether it should work in = general. Take for example \&: is this LICR, or is it a category 12 `&' token that = is in LICR, or is the LICR missing a \textampersand command? I don't know, = but I suspect the matter is still undecided. Some documentation for the file under discussion might be a good place = as any to start with a more precise definition of the LICR. Lars Hellstr=F6m ------_=_NextPart_001_01C2CB8D.4B109380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: latex/3480: Support for UTF-8 missing in = inputenc.sty

At 10.32 +0100 2003-02-03, David Carlisle = wrote:
>
>> Ideally I think that I'd like the latex = field to consistently have
>> a command that could be used as latex's = internal encoding independent
>> command, together with some latex packages = to define any additional
>> commands needed, so you could switch at the = latex level between
>> displaying the glyph, or faking it with TeX = constructs or making a
>> missing-glyph marker, depending on the fonts = available.
>
>That's just another way of saying the latex field = should have LICR
>commands. For Latex use only it would be just as = easy to define the
>mappings directly in the latex package files but = having them in that XML
>would I think help translators from XML = (especially MathML) to TeX to
>come up with consistent mappings, as all the = MathML entities and
>character documentation is derived from = there.

IMO some definition of the LICR commands which is = distinct from the code in
the LaTeX packages is needed, since the current state = of things is rather
implicit. It is possible to see that something works = in all cases one can
think of, but it is not possible to see whether it = should work in general.
Take for example \&: is this LICR, or is it a = category 12 `&' token that is
in LICR, or is the LICR missing a \textampersand = command? I don't know, but
I suspect the matter is still undecided.

Some documentation for the file under discussion might = be a good place as
any to start with a more precise definition of the = LICR.

Lars Hellstr=F6m

------_=_NextPart_001_01C2CB8D.4B109380--