Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f4R9sRf25129 for ; Sun, 27 May 2001 11:54:27 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4R9sR726732 . for ; Sun, 27 May 2001 11:54:27 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E693.041D8B80" Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f4R9sQ016122 for ; Sun, 27 May 2001 11:54:26 +0200 (MET DST) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA16252 for ; Sun, 27 May 2001 11:54:26 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f4R9sP016114 for ; Sun, 27 May 2001 11:54:25 +0200 (MET DST) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <3.F64D2FAE@mail.listserv.gmd.de>; Sun, 27 May 2001 11:52:26 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 496956 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 27 May 2001 11:54:22 +0200 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA06707 for ; Sun, 27 May 2001 11:54:21 +0200 (MET DST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id LAA150540 for ; Sun, 27 May 2001 11:54:21 +0200 Received: from smtp.wanadoo.es (m1smtpisp02.wanadoo.es [62.36.220.21] (may be forged)) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4R9sL114009 for ; Sun, 27 May 2001 11:54:22 +0200 (MET DST) Received: from [62.36.68.2] (62-36-68-2.dialup.uni2.es [62.36.68.2]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f4R9sBI23611 for ; Sun, 27 May 2001 11:54:12 +0200 (MET DST) Return-Path: X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Content-class: urn:content-classes:message Subject: Re: \InputTranslation Date: Sun, 27 May 2001 11:20:04 +0100 Message-ID: <200105270954.f4R9sBI23611@smtp.wanadoo.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Javier Bezos" Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4109 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E693.041D8B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marcel writes: > - Regarding Javier's above example: I think this is the correct and > expected behavior. I want to be able to able to write: > > \begin{chinese} > \newcommand{\foo}{***something chinese***} > \newcommand{\bar}{***and some more chinese***} > \end{chinese} > > The chinese characters \foo\ and \bar\ are not easy to enter on a > western keyboard. If you need to frequently use \foo\ in your > scholarly discussion of Chinese literature, it is better to first > define macros for all the chinese characters you need, and then just > write \verb|\foo| whenever you need \foo. While desirable, this behaviour won't be necessarily corrrect. The = issues are - how to record the context which \foo\ and \bar\ were defined in? - is the context actually relevant (from both TeX and users points of = view)? If I say \begin{mandarin} \newcommand{\foo}{} \end{mandarin} how TeX knows that \foo\ was defined in a Mandarin context (including perhaps input encoding information)? And what is expected by the user, that the Chinese char should be considered "conceptual" (thus rendered differently in Japanese and Mandarin) or that the Chinese char must be rendered with the simplified ideogram (ie, Mandarin vs. Japanese)? What makes that different from, say, \newcommand{\foo}{\unichar{}} (without specifying the language)? A possible solution [at least, the solution I took in my proposal] is to add a set of macros (\ensurelanguage and \ensuredcommand) which records the apropiate information. The problem, of course, is that if they are used in a wrong way, the definition will become a mess, so a better approach seems advisable. Javier ------_=_NextPart_001_01C0E693.041D8B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: \InputTranslation

Marcel writes:

> - Regarding Javier's above example: I think this = is the correct and
>   expected behavior.  I want to = be able to able to write:
>
>   \begin{chinese}
>     = \newcommand{\foo}{***something chinese***}
>     \newcommand{\bar}{***and = some more chinese***}
>   \end{chinese}
>
>   The chinese characters \foo\ and = \bar\ are not easy to enter on a
>   western keyboard.  If you need = to frequently use \foo\ in your
>   scholarly discussion of Chinese = literature, it is better to first
>   define macros for all the chinese = characters you need, and then just
>   write \verb|\foo| whenever you need = \foo.

While desirable, this behaviour won't be necessarily = corrrect. The issues
are
- how to record the context which \foo\ and \bar\ = were defined in?
- is the context actually relevant (from both TeX and = users points of view)?

If I say

  \begin{mandarin}
    \newcommand{\foo}{<Unicode char = corresponding to Chinese ai>}
  \end{mandarin}

how TeX knows that \foo\ was defined in a Mandarin = context (including
perhaps input encoding information)? And what is = expected by the user,
that the Chinese char should be considered = "conceptual" (thus rendered
differently in Japanese and Mandarin) or that the = Chinese char must be
rendered with the simplified ideogram (ie, Mandarin = vs. Japanese)?
What makes that different from, say,
  \newcommand{\foo}{\unichar{<Unicode = code>}}
(without specifying the language)?


A possible solution [at least, the solution I took in = my proposal] is to
add a set of macros (\ensurelanguage and = \ensuredcommand) which records
the apropiate information. The problem, of course, is = that if they are
used in a wrong way, the definition will become a = mess, so a better
approach seems advisable.


Javier

------_=_NextPart_001_01C0E693.041D8B80--