Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 13:17:35 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0GCHU6C018502 for ; Thu, 16 Jan 2003 13:17:33 +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 h0GCAJwO016536; Thu, 16 Jan 2003 13:10:20 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BD59.40669980" 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 h0G9IdqN006731; Thu, 16 Jan 2003 13:02:29 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8350 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 16 Jan 2003 13:02:29 +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 h0GC2Tkr008392 for ; Thu, 16 Jan 2003 13:02:29 +0100 Received: from mailgate.rz.uni-karlsruhe.de (exim@mailgate.rz.uni-karlsruhe.de [129.13.64.97]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0GC8OwQ015872 for ; Thu, 16 Jan 2003 13:09:23 +0100 (MET) Received: from g113.hadiko.de (root@hadig113.hadiko.uni-karlsruhe.de [172.20.43.13]) by mailgate.rz.uni-karlsruhe.de with esmtp (Exim 3.36 #1) id 18Z8Tm-0002s3-00; Thu, 16 Jan 2003 12:46:38 +0100 Received: (from nil@localhost) by g113.hadiko.de (8.11.1/8.11.1/Debian 8.11.0-6) id h0GBkcB17215 for LATEX-L@listserv.uni-heidelberg.de; Thu, 16 Jan 2003 12:46:38 +0100 In-Reply-To: <15899.14827.804209.458595@istrati.mittelbach-online.de> References: <200212031601.gB3G11cQ009558@sun.dante.de> <15899.14827.804209.458595@istrati.mittelbach-online.de> Return-Path: X-OriginalArrivalTime: 16 Jan 2003 12:17:35.0921 (UTC) FILETIME=[40F32210:01C2BD59] User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -2.2 () IN_REP_TO,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_MUTT Content-class: urn:content-classes:message Subject: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Date: Thu, 16 Jan 2003 12:46:37 +0100 Message-ID: A<20030116114637.GA9844@g113.hadiko.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Thread-Index: AcK9WUEQCv/fkASoRByliuer0Iycfg== From: "Dominique Unruh" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4432 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BD59.40669980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I want to add several comments to Frank and Chris's utf8.def: =3D=3D=3D 1. The definition of the .dfu files. In the present model, we have the problem, that the same Unicode character is defined several times in several .dfu files. If all definitions are identical, this is no problem, but this has to be ensured. Take the following example: Fontencoding LGR has the command \euro, to be assigned to U+20AC, while TS1 has \texteuro, same Unicode character. Therefore I propose the following policy: - Unicode to TeX mappings are done in a single, fontencoding independent file, e.g. ucs.map: [...] 0x20AC \texteuro [...] - Fontencoding specific files contain list of supported code positions, e.g. lgr.ucr and ts1.ucr (UCR=3D Unicode Range) both contain the number 0x20AC (but no more information). - A script then generates the .dfu files, the above example induces the inclusion of \DeclareUnicodeCharacter{20AC}{\texteuro} into ts1.dfu and lgr.dfu (LGR has then to be updated to include the macro \texteuro additionally to \euro). Note that only the final .dfu files are seen by the latex executable, so this system does not involve any changes in utf8.def. - The ucs.map file is managed by the LaTeX team. The .ucr files can be created be the developers of the fontencodings, thus enabling the developement of fontencodings without the need of interaction with the LaTeX team. Inclusion of new into the ucs.map file should not be subject to some restrictive election, since no resources are wasted, unless some fontencoding requests these characters. - To the private area algoritmically generatable names should be assigned, e.g. U+F8D0 (Klingon A according to http://www.evertype.com/standards/csur/klingon.html) should map to something like \unicodefBdO (some thought has to be given to the fact, that the names may not contain numbers) and not e.g. \klingona. =3D=3D=3D 2. \IeC Most characters must be enclosed in a call to \IeC, like it is also done by \DeclareInputText. Otherwise the following fragment \tableofcontents \section{La=DF nach} % La\ss nach will give a TOC entry "La=DFnach" (i.e. the space will go away). =3D=3D=3D 3. Unicode to LaTeX mappings. There are already extensive lists of character mappings available at: http://www.unruh.de/DniQ/latex/unicode/content/config/ =3D=3D=3D 4. The loading of the .dfu files. It has been mentioned, that the late loading of the .dfu files (lines 113--124) causes problems with saveboxes. For completeness I'd like to add, that also \xdef's etc. cause similar problems when used in the preamble. =3D=3D=3D 5. Interoperability with ucs.sty There are some name clashes with my Unicode package. - utf8.def: I accept the fact, that this is the canonical name for that file and will rename my inputencoding in favour of the kernel's encoding. - \DeclareUnicodeCharacter: This command is named identically in my system. I would appreciate if another name could be chosen at this early stadium to evade chaos. Some possible names would be \DeclareUnicodeGlyph (according to the nomenclature of the Unicode = standard) \DeclareUnicodeCommand (analogous to \DeclareTextCommand) DniQ. ------_=_NextPart_001_01C2BD59.40669980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: latex/3480: Support for UTF-8 missing in = inputenc.sty

I want to add several comments to Frank and Chris's = utf8.def:


=3D=3D=3D 1. The definition of the .dfu files.

In the present model, we have the problem, that the = same Unicode
character is defined several times in several .dfu = files. If all
definitions are identical, this is no problem, but = this has to be
ensured. Take the following example: Fontencoding LGR = has the command
\euro, to be assigned to U+20AC, while TS1 has = \texteuro, same Unicode
character. Therefore I propose the following = policy:

- Unicode to TeX mappings are done in a single, = fontencoding
independent file, e.g. ucs.map:
[...]
0x20AC   \texteuro
[...]

- Fontencoding specific files contain list of = supported code
positions, e.g.  lgr.ucr and ts1.ucr (UCR=3D = Unicode Range) both contain
the number 0x20AC (but no more information).

- A script then generates the .dfu files, the above = example induces
the inclusion of

\DeclareUnicodeCharacter{20AC}{\texteuro}

into ts1.dfu and lgr.dfu (LGR has then to be updated = to include the
macro \texteuro additionally to \euro). Note that = only the final .dfu
files are seen by the latex executable, so this = system does not
involve any changes in utf8.def.

- The ucs.map file is managed by the LaTeX team. The = .ucr files can be
created be the developers of the fontencodings, thus = enabling the
developement of fontencodings without the need of = interaction with the
LaTeX team. Inclusion of new into the ucs.map file = should not be
subject to some restrictive election, since no = resources are wasted,
unless some fontencoding requests these = characters.

- To the private area algoritmically generatable names = should be
assigned, e.g. U+F8D0 (Klingon A according to
http://www.e= vertype.com/standards/csur/klingon.html) should map to
something like \unicodefBdO (some thought has to be = given to the fact,
that the names may not contain numbers) and not e.g. = \klingona.


=3D=3D=3D 2. \IeC

Most characters must be enclosed in a call to \IeC, = like it is also
done by \DeclareInputText. Otherwise the following = fragment

\tableofcontents
\section{La=DF nach}  % La\ss  nach

will give a TOC entry "La=DFnach" (i.e. the = space will go away).



=3D=3D=3D 3. Unicode to LaTeX mappings.

There are already extensive lists of character = mappings available at:
http://ww= w.unruh.de/DniQ/latex/unicode/content/config/



=3D=3D=3D 4. The loading of the .dfu files.

It has been mentioned, that the late loading of the = .dfu files (lines
113--124) causes problems with saveboxes. For = completeness I'd like to
add, that also \xdef's etc. cause similar problems = when used in the
preamble.



=3D=3D=3D 5. Interoperability with ucs.sty

There are some name clashes with my Unicode = package.

- utf8.def: I accept the fact, that this is the = canonical name for
that file and will rename my inputencoding in favour = of the kernel's
encoding.

- \DeclareUnicodeCharacter: This command is named = identically in my
system. I would appreciate if another name could be = chosen at this
early stadium to evade chaos. Some possible names = would be

\DeclareUnicodeGlyph (according to the nomenclature of = the Unicode standard)
\DeclareUnicodeCommand (analogous to = \DeclareTextCommand)


DniQ.

------_=_NextPart_001_01C2BD59.40669980--