LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
Date: Mon, 3 Feb 2003 23:36:11 +0100
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
In-Reply-To: <200302032213.WAA18704@e3000>
Content-Type: text/plain; charset=us-ascii
From: Frank Mittelbach <[log in to unmask]>
Parts/Attachments: text/plain (49 lines)
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
some sensible changes added)

 > 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
your home machine



frank

ATOM RSS1 RSS2