## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Condense Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```David Carlisle writes:

> > right, but the question is the ownership of data. I think it would be a
> > good idea for us (LaTeX/TeX world) to maintain a source file that gives
> > the mapping from unicode to LICR (having decided what the LICR's are).
>
> of course the hard bit, as you imply, is the bit in brackets. I can see

well, not too difficult. it mainly needs documentation, right? (and of course
getting that file correct or those files)

i'm currently writing a documentation about the LICR for the LaTeX Companion
but i'm not too worried about changing that depending on discussions, eg

one could basically live with what's currently around and establied by usage,
eg short sequences from the ..enc.def files and plain.tex

or one could define stuff like \# as shortcuts to real LICR objects like
\textampersand

or ...

I don't really think it matters that much once it has been officially
documented

solving the LICR to math mapping is another matter but there again i think
something along the lines of inpmath would provide the right interface (with

> that looking from your side the unicode.xml file looks a bit remote and
> out of reach, so I understand the concern (and agree) that the mapping
> should be more visibly in latex control. Of course from my side the
> distinction is rather more blurred as the master copy of that file is
> effectively on my machine here...

i actually guessed that :-) still i think the proper political way as you said is

> > The move from that file to the unicode file could then be done by some
> > automated process
>
> Fair enough, politically that may be the best way to go.

the master files including the conversion bit of perl code could still live on