> [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,
> > [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
> perhaps using docstrip to generate the standard dfu files from that
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
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
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
I see it more as an alternative, in case that you need advanced
> > - \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.
> what are your arguments?
1. Someone uses that command in some package or document. Then using the wrong
utf8.def will lead to inintelligible errors, instead of the more
helpful "undefined command".
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
\DeclareUnicodeMapping % the LaTeX may be guessed
\DeclareUnicodeInput % like in inputenc
\DeclareUnicodeInputText % like in inputenc