Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Feb 2003 10:45:45 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h139jd6C017395 for ; Mon, 3 Feb 2003 10:45:44 +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 h139YQtt022924; Mon, 3 Feb 2003 10:34:27 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2CB69.05DA6A80" 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 h133iQ9N031075; Mon, 3 Feb 2003 10:25:35 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 6702 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 3 Feb 2003 10:25:35 +0100 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 h139PZ5f032719 for ; Mon, 3 Feb 2003 10:25:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail22.messagelabs.com (mail22.messagelabs.com [193.109.255.115]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with SMTP id h139X9tt022413 for ; Mon, 3 Feb 2003 10:33:10 +0100 (MET) Received: (qmail 11072 invoked from network); 3 Feb 2003 09:32:57 -0000 Received: from smtp-2.star.net.uk (212.125.75.71) by server-23.tower-22.messagelabs.com with SMTP; 3 Feb 2003 09:32:57 -0000 Received: (qmail 12965 invoked from network); 3 Feb 2003 09:33:02 -0000 Received: from nagmx1.nag.co.uk (HELO nag.co.uk) (62.231.145.242) by smtp-2.star.net.uk with SMTP; 3 Feb 2003 09:33:02 -0000 Received: from penguin.nag.co.uk (IDENT:root@penguin.nag.co.uk [192.156.217.14]) by nag.co.uk (8.9.3/8.9.3) with ESMTP id JAA02239 for ; Mon, 3 Feb 2003 09:32:53 GMT Received: by penguin.nag.co.uk (8.9.3) id JAA05953; Mon, 3 Feb 2003 09:32:48 GMT In-Reply-To: <15933.43565.751843.247809@istrati.mittelbach-online.de> (message from Frank Mittelbach on Mon, 3 Feb 2003 00:30:53 +0100) References: <200301311603.QAA22049@penguin.nag.co.uk> <15933.43565.751843.247809@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 03 Feb 2003 09:45:49.0242 (UTC) FILETIME=[0861B1A0:01C2CB69] X-VirusChecked: Checked X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -1.3 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_02_03 X-Env-Sender: davidc@nag.co.uk X-Msg-Ref: server-23.tower-22.messagelabs.com!1044264777!2133 Content-class: urn:content-classes:message Subject: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Date: Mon, 3 Feb 2003 10:32:48 +0100 Message-ID: A<200302030932.JAA05953@penguin.nag.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Thread-Index: AcLLaQiAG9FRWgLRSduow8Qzujyapg== From: "David Carlisle" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4526 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2CB69.05DA6A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > well, if we would like to see decent TeX support it might be good to = get some > grip on that but first it would need a clear understanding of the = fields, eg > what is the text/math notation supposed to mean? is this also TeX = related? I think the jadetex back end uses tex text/math distinction to decide whether to stick \ensuremath around the character. The (La)TeX parts are as you say, a bit strange in places and have some undocumented (and possibly unknown) dependencies on external packages (I couldn't get the cyrillic to work last time I tried). There hasn't been any work on the latex fields since the inital jadetex work of Sebastian. All the recent effort has been on keeping the character descriptions up to date as the unicode 3.1 and 3.2 proposals for mathematical characters progressed through unicode/ISO and kept shuffling the set of characters. I mentioned the file not because I thought that the current TeX mappings are necessarily the best but because it's a start, and if we update that file its easy to generate unicode/xml -> tex mappings in various formats. > i guess with a suitable utf8 support plus a suitable translation from > fontencoding specific commands (LICR) to math commands, (ie something = like > inpmath) we could come up with a list for unicode that would allow = better > support than what is currently in that file, since that would then = work > consistently throughout text and math selecting the right glyphs = inside TeX as > needed Agreed, basically when I said to Roozbeh > 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. David ________________________________________________________________________ This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________ ------_=_NextPart_001_01C2CB69.05DA6A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: latex/3480: Support for UTF-8 missing in = inputenc.sty

> well, if we would like to see decent TeX support = it might be good to get some
> grip on that but first it would need a clear = understanding of the fields, eg
> what is the text/math notation supposed to mean? = is this also TeX related?


I think the jadetex back end uses tex text/math
distinction to decide whether to stick \ensuremath = around the character.

The (La)TeX parts are as you say, a bit strange in = places and have some
undocumented (and possibly unknown) dependencies on = external packages
(I couldn't get the cyrillic to work last time I = tried). There hasn't
been any work on the latex fields since the inital = jadetex work of
Sebastian. All the recent effort has been on keeping = the character
descriptions up to date as the unicode 3.1 and 3.2 = proposals for
mathematical characters progressed through = unicode/ISO and kept
shuffling the set of characters. I mentioned the file = not because I
thought that the current TeX mappings are necessarily = the best but
because it's a start, and if we update that file its = easy to generate
unicode/xml -> tex mappings in various = formats.

> i guess with a suitable utf8 support plus a = suitable translation from
> fontencoding specific commands (LICR) to math = commands, (ie something like
> inpmath) we could come up with a list for = unicode that would allow better
> support than what is currently in that file, = since that would then work
> consistently throughout text and math selecting = the right glyphs inside TeX as
> needed

Agreed, basically when I said to Roozbeh


> 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.

David


________________________________________________________________= ________
This e-mail has been scanned for all viruses by Star = Internet. The
service is powered by MessageLabs. For more = information on a proactive
anti-virus service working around the clock, around = the globe, visit:
http://www.star.net.uk
________________________________________________________________= ________

------_=_NextPart_001_01C2CB69.05DA6A80--