LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dominique Unruh <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 16 Jan 2003 12:46:37 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (92 lines)
I want to add several comments to Frank and Chris's utf8.def:


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


=== 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ß nach}  % La\ss  nach

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



=== 3. Unicode to LaTeX mappings.

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



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



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

ATOM RSS1 RSS2