> [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...{% ... \if@alreadydefined \ifx\olddefinition\newdefinition\else \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 > > early stadium to evade chaos. > > what are your arguments? Two scenarios: 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 Which? > \DeclareUnicodeLaTeXMapping Or: \DeclareUnicodeMapping % the LaTeX may be guessed \DeclareUnicodeInput % like in inputenc \DeclareUnicodeInputText % like in inputenc DniQ.