LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

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

Print Reply
Frank Mittelbach <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Fri, 17 Jan 2003 23:56:38 +0100
text/plain (134 lines)
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 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

 > >  > There are already extensive lists of character mappings available at:
 > >  >
 > > so there is, worth stealing from
 > Perhaps I should add, that some of the macros rely on fontencodings
 > written by my own
 > ( and some need
 > extended fontencodings
 > ( 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.


 > > 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