Dominique wrote: > > [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. not quite so. i agree \euro is not perfect here. but that package explicitly does not attempt to set up an encoding specific command but a command independent of encodings at least that is the way i see it (tonight :-) > > > [about incompatible double definitions of Unicode chars] > 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 > ...} yes we could do that as it happens only at declaration time this is a onetime effort so no problem > > > > [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. if you use that generic idea of a script :-) then we are proposing the same i guess > > > 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). yes understood from what i saw > > would it be possible for you to give use a ten line bullet list of > > comparsion? > > I will do so in the next days. fine > > 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. that was what i thought too, good that we didn't step on your toes then by proposing something else > > > - \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: sorry, misunderstanding, i meant quite literally the semantics of the arguments for your \DeclareUnicodecharacter macro, ie what goes into #1 ... > 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). question is how both could coexist and if they can whether they can use the same database of \DeclareUnicodecharacter declarations rather than doubling the space > > > \DeclareUnicodeCommand (analogous to \DeclareTextCommand) > > no again Command in that context has already some semantics > > Which? \...Command has been used always to refer to the more generalised version of something, eg % |\DeclareTextComposite| is the most common example of using % the more general declaration % |\DeclareTextCompositeCommand|, which can define a composite where rather than having the target definition part very much in a defined syntax the "Command" version allows general code > > \DeclareUnicodeLaTeXMapping > > Or: > \DeclareUnicodeMapping % the LaTeX may be guessed > \DeclareUnicodeInput % like in inputenc > \DeclareUnicodeInputText % like in inputenc neither sounds too bad :-) but too late at night for me to really think about it frank