LATEX-L Archives

Mailing list for the LaTeX3 project


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

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Dominique Unruh <[log in to unmask]>
Fri, 17 Jan 2003 23:33:46 +0100
text/plain; charset=us-ascii
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (95 lines)
> [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,

\if@alreadydefined \ifx\olddefinition\newdefinition\else

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

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

> 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

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


>  \DeclareUnicodeLaTeXMapping

\DeclareUnicodeMapping % the LaTeX may be guessed
\DeclareUnicodeInput % like in inputenc
\DeclareUnicodeInputText % like in inputenc