## 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 >>]

 Subject: Re: latex/3480: Support for UTF-8 missing in inputenc.sty From: Dominique Unruh <[log in to unmask]> Reply To: Mailing list for the LaTeX3 project <[log in to unmask]> Date: Fri, 17 Jan 2003 23:33:46 +0100 Content-Type: text/plain Parts/Attachments: text/plain (95 lines)
> [aside, where is that file, the one that i have here is very short
> and doesn't contain \euro but neither looks like a proper encoding
> file either]

Yes. I'm sorry, I seem to have mixed. It was the eurofont package
that used the \euro command. But it shows the problem nevertheless.

> > [about incompatible double definitions of Unicode chars]
> being pragmatic i believe that these get weed out after a while, the reason
> for suggesting a .dfu file approach is that this allows easy extensions for
> locally developed encodings.

In this case there should be at least some checking of redefinition,
like

\def\DeclareUnicodeCharacter...{%
...
\output@fierce@warning@or@error\fi\fi
...}

> > [about generating .dfu files by a script]
> a ucs.map file that contains the mappings Unicode->LICR  in the form directly
> usable in .dfu files, simply as a template for making a .dfu if really
> necessary.
>
> perhaps using docstrip to generate the standard dfu files from that
> file

Yes. I like that approach. In fact, this is like just implementing the
"script" in LaTeX.

>  > There are already extensive lists of character mappings available at:
>  > http://www.unruh.de/DniQ/latex/unicode/content/config/
> so there is, worth stealing from

Perhaps I should add, that some of the macros rely on fontencodings
written by my own
(http://www.unruh.de/DniQ/latex/unicode/content/contrib) and some need
extended fontencodings
(http://www.unruh.de/DniQ/latex/unicode/content/ucsencs.def contains
the additional macros), where the fontencodings are not complete
enough (e.g. LGR).

> would it be possible for you to give use a ten line bullet list of
> comparsion?

I will do so in the next days.

> perhaps the best is simply to forget about what we did on lazy afternoons
> during the Xmas holidays?

I don't think so. My package has one big disadvantage: Since it tries
do support all and everything, it is huge and slow (and probably full
of bugs). I don't think, it is suited for inclusion into the LaTeX
kernel itself.

I see it more as an alternative, in case that you need advanced
features.

>  > - \DeclareUnicodeCharacter: This command is named identically in my
>  > system. I would appreciate if another name could be chosen at this
>

Two scenarios:

1. Someone uses that command in some package or document. Then using the wrong

2. Someone tries to use both inputencs in a single document. (Perhaps
because he wants to typeset most of the document with the fast
in-kernel implementation, and some few strings containing combining
chars with my implementation).

> no we map to LICR those are characters not glyphs!

On second thought: true.

>  > \DeclareUnicodeCommand (analogous to \DeclareTextCommand)
> no again Command in that context has already some semantics

Which?

>  \DeclareUnicodeLaTeXMapping

Or:
\DeclareUnicodeMapping % the LaTeX may be guessed
\DeclareUnicodeInput % like in inputenc
\DeclareUnicodeInputText % like in inputenc

DniQ.