Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Sat, 18 Jan 2003 00:04:44 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h0HN4f6C024850 for ; Sat, 18 Jan 2003 00:04:42 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0HMwrEV005976; Fri, 17 Jan 2003 23:58:53 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2BE7C.D2B38E00" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0H4jk5X014095; Fri, 17 Jan 2003 23:51:54 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 7566 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Fri, 17 Jan 2003 23:51:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h0HMpskr021808 for ; Fri, 17 Jan 2003 23:51:54 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h0HMwpEV005961 for ; Fri, 17 Jan 2003 23:58:51 +0100 (MET) Received: from [212.227.126.161] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 18ZfRr-0000wl-00 for LATEX-L@listserv.uni-heidelberg.de; Fri, 17 Jan 2003 23:58:51 +0100 Received: from [80.129.6.107] (helo=istrati.mittelbach-online.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 18ZfRq-0007A7-00 for LATEX-L@listserv.uni-heidelberg.de; Fri, 17 Jan 2003 23:58:50 +0100 Received: (from frank@localhost) by istrati.mittelbach-online.de (8.11.2/8.11.2/SuSE Linux 8.11.1-0.5) id h0HMucv05087; Fri, 17 Jan 2003 23:56:39 +0100 In-Reply-To: <20030117223345.GA14828@g113.hadiko.de> References: <200212031601.gB3G11cQ009558@sun.dante.de> <15899.14827.804209.458595@istrati.mittelbach-online.de> <20030116114637.GA9844@g113.hadiko.de> <15912.23044.419984.897093@istrati.mittelbach-online.de> <20030117223345.GA14828@g113.hadiko.de> Return-Path: X-Mailer: VM 6.96 under Emacs 20.7.1 X-OriginalArrivalTime: 17 Jan 2003 23:04:44.0282 (UTC) FILETIME=[D2DE95A0:01C2BE7C] X-Authentication-Warning: istrati.mittelbach-online.de: frank set sender to frank@mittelbach-online.de using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -0.7 () IN_REP_TO,REFERENCES,SPAM_PHRASE_02_03,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Date: Fri, 17 Jan 2003 23:56:38 +0100 Message-ID: A<15912.35366.899220.996696@istrati.mittelbach-online.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: latex/3480: Support for UTF-8 missing in inputenc.sty Thread-Index: AcK+fNL7yGiXQt2STjWM19MBuIDi+A== From: "Frank Mittelbach" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4435 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2BE7C.D2B38E00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 ------_=_NextPart_001_01C2BE7C.D2B38E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: latex/3480: Support for UTF-8 missing in = inputenc.sty

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://ww= w.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://ww= w.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

------_=_NextPart_001_01C2BE7C.D2B38E00--