Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Tue, 4 Feb 2003 00:01:22 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h13N1K6C019912 for ; Tue, 4 Feb 2003 00:01:21 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h13Mcbtt021300; Mon, 3 Feb 2003 23:38:38 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CBD8.2B528D00" 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 h133iQVf031075; Mon, 3 Feb 2003 23:30:55 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7904 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 3 Feb 2003 23:30:55 +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 h13MUtPw006996 for ; Mon, 3 Feb 2003 23:30:55 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h13Mcatt021286 for ; Mon, 3 Feb 2003 23:38:36 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18fpEa-0005F1-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 03 Feb 2003 23:38:36 +0100 Received: from [80.129.10.104] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18fpEa-0003l1-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 03 Feb 2003 23:38:36 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h13MaBZ11851; Mon, 3 Feb 2003 23:36:11 +0100 In-Reply-To: <200302032213.WAA18704@e3000> References: <630BE70C8320D6118D240002A589ABB204A9504F@DERUM201> <200302032213.WAA18704@e3000> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 03 Feb 2003 23:01:22.0979 (UTC) FILETIME=[2BE7EF30:01C2CBD8] X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.6 () EMAIL_ATTRIBUTION,IN_REP_TO,REFERENCES,SPAM_PHRASE_01_02,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: AW: latex/3480: Support for UTF-8 missing in inputenc.sty Date: Mon, 3 Feb 2003 23:36:11 +0100 Message-ID: A<15934.61147.763316.792827@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: AW: latex/3480: Support for UTF-8 missing in inputenc.sty Thread-Index: AcLL2CxPr9fIja2BSbS5lqXmkv0jMw== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4532 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CBD8.2B528D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Carlisle writes: > > right, but the question is the ownership of data. I think it would = be a > > good idea for us (LaTeX/TeX world) to maintain a source file that = gives > > the mapping from unicode to LICR (having decided what the LICR's = are). > > of course the hard bit, as you imply, is the bit in brackets. I can = see well, not too difficult. it mainly needs documentation, right? (and of = course getting that file correct or those files) i'm currently writing a documentation about the LICR for the LaTeX = Companion but i'm not too worried about changing that depending on discussions, eg one could basically live with what's currently around and establied by = usage, eg short sequences from the ..enc.def files and plain.tex or one could define stuff like \# as shortcuts to real LICR objects = like \textampersand or ... I don't really think it matters that much once it has been officially documented solving the LICR to math mapping is another matter but there again i = think something along the lines of inpmath would provide the right interface = (with some sensible changes added) > that looking from your side the unicode.xml file looks a bit remote = and > out of reach, so I understand the concern (and agree) that the = mapping > should be more visibly in latex control. Of course from my side the > distinction is rather more blurred as the master copy of that file is > effectively on my machine here... i actually guessed that :-) still i think the proper political way as = you said is > > The move from that file to the unicode file could then be done by = some > > automated process > > Fair enough, politically that may be the best way to go. the master files including the conversion bit of perl code could still = live on your home machine frank ------_=_NextPart_001_01C2CBD8.2B528D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: AW: latex/3480: Support for UTF-8 missing in = inputenc.sty

David Carlisle writes:

 > > right, but the question is the = ownership of data. I think it would be a
 > > good idea for us (LaTeX/TeX world) to = maintain a source file that gives
 > > the mapping from unicode to LICR = (having decided what the LICR's are).
 >
 > of course the hard bit, as you imply, is = the bit in brackets. I can see

well, not too difficult. it mainly needs = documentation, right? (and of course
getting that file correct or those files)

i'm currently writing a documentation about the LICR = for the LaTeX Companion
but i'm not too worried about changing that depending = on discussions, eg

 one could basically live with what's currently = around and establied by usage,
eg short sequences from the ..enc.def files and = plain.tex

 or one could define stuff like \# as shortcuts = to real LICR objects like
\textampersand

or ...

I don't really think it matters that much once it has = been officially
documented

solving the LICR to math mapping is another matter but = there again i think
something along the lines of inpmath would provide = the right interface (with
some sensible changes added)

 > that looking from your side the unicode.xml = file looks a bit remote and
 > out of reach, so I understand the concern = (and agree) that the mapping
 > should be more visibly in latex control. = Of course from my side the
 > distinction is rather more blurred as the = master copy of that file is
 > effectively on my machine here...

i actually guessed that :-) still i think the proper = political way as you said is

 > > The move from that file to the unicode = file could then be done by some
 > > automated process
 >
 > Fair enough, politically that may be the = best way to go.

the master files including the conversion bit of perl = code could still live on
your home machine



frank

------_=_NextPart_001_01C2CBD8.2B528D00--