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 f4K9TIf20812 for ; Sun, 20 May 2001 11:29:18 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4K9TH721998 . for ; Sun, 20 May 2001 11:29:17 +0200 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 f4K9TH021509 for ; Sun, 20 May 2001 11:29:17 +0200 (MET DST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0E10F.57CA2B00" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id LAA19058 for ; Sun, 20 May 2001 11:29:17 +0200 (MEST) Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f4K9TGU22718 for ; Sun, 20 May 2001 11:29:16 +0200 (MET DST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <8.513E60CC@mail.listserv.gmd.de>; Sun, 20 May 2001 11:27:29 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 495680 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 20 May 2001 11:29:13 +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 LAA26732 for ; Sun, 20 May 2001 11:29:11 +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 LAA52112 for ; Sun, 20 May 2001 11:29:12 +0200 Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4K9TAj18410 for ; Sun, 20 May 2001 11:29:10 +0200 (MET DST) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.22 #1) id 151PWJ-00056A-00; Sun, 20 May 2001 11:29:03 +0200 Received: from b0f80.pppool.de ([213.7.15.128] helo=hoelderlin.localdomain) by mx0.freenet.de with esmtp (Exim 3.22 #1) id 151PWJ-00053l-00; Sun, 20 May 2001 11:29:03 +0200 Received: (from marcel@localhost) by hoelderlin.localdomain (8.9.3/8.8.7) id LAA00471; Sun, 20 May 2001 11:25:50 +0200 In-Reply-To: References: <200105161742.MAA02503@riemann.math.twsu.edu> Return-Path: X-Mailer: VM 6.90 under Emacs 20.4.1 X-Authentication-Warning: hoelderlin.localdomain: marcel set sender to marcel@hoelderlin.localdomain using -f Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Sun, 20 May 2001 10:25:50 +0100 Message-ID: <15111.36254.279748.954703@hoelderlin.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Marcel Oliver" 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: 4090 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0E10F.57CA2B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hans Aberg writes: > I think it would be unwise to impose any kind of restrictions onto > the math characters in the default settings: If they appears as > distinct entities, one is free to use them as that. I have to agree with Hans on this one. Typesetting math the way it is done in TeX _is_ visual mark-up, while (most of) the textual mark-up in LaTeX is logical mark-up. So a distinct MICR will not gain anything (and probably cause multiple problems) unless we support full logical mark-up. However, this is really a red herring. IMHO it will render LaTeX basically unusable for tasks it currently excels in (communication between human (!) mathematicians), and not add anything to areas where logical markup is required (because LaTeX would not be able to use most of the additional information anyway). This leaves two issues: - Mapping Unicode into the current TeX (plus AMS-fonts etc.) naming scheme, so that people will eventually be able to use a Unicode enabled editor for their source files. Since people from the AMS (and other math publishers?) have been working on the Unicode math planes, I assume that this is essentially understood. - "Lost character conditions": If a font does not provide all variations of a symbol that TeX or Unicode define, it should not quietly resort to a many-to-one mapping, i.e., at least a warning must be issued. This also seems fairly natural. Marcel ------_=_NextPart_001_01C0E10F.57CA2B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

Hans Aberg writes:
 > I think it would be unwise to impose any = kind of restrictions onto
 > the math characters in the default = settings: If they appears as
 > distinct entities, one is free to use them = as that.

I have to agree with Hans on this one.  = Typesetting math the way it is
done in TeX _is_ visual mark-up, while (most of) the = textual mark-up
in LaTeX is logical mark-up.

So a distinct MICR will not gain anything (and = probably cause multiple
problems) unless we support full logical = mark-up.  However, this is
really a red herring.  IMHO it will render LaTeX = basically unusable
for tasks it currently excels in (communication = between human (!)
mathematicians), and not add anything to areas where = logical markup is
required (because LaTeX would not be able to use most = of the
additional information anyway).

This leaves two issues:

- Mapping Unicode into the current TeX (plus AMS-fonts = etc.) naming
  scheme, so that people will eventually be able = to use a Unicode
  enabled editor for their source files.  = Since people from the AMS
  (and other math publishers?) have been working = on the Unicode math
  planes, I assume that this is essentially = understood.

- "Lost character conditions":  If a = font does not provide all
  variations of a symbol that TeX or Unicode = define, it should not
  quietly resort to a many-to-one mapping, i.e., = at least a warning
  must be issued.  This also seems fairly = natural.

Marcel

------_=_NextPart_001_01C0E10F.57CA2B00--