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 f1CKwRH21829 for ; Mon, 12 Feb 2001 21:58:27 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1CKwQd30798 . for ; Mon, 12 Feb 2001 21:58:26 +0100 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 f1CKwP729702 for ; Mon, 12 Feb 2001 21:58:25 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09536.8BA51B80" 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 VAA16182 for ; Mon, 12 Feb 2001 21:58:25 +0100 (MET) 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 f1CKwPM16479 for ; Mon, 12 Feb 2001 21:58:25 +0100 (MET) 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 <2.5EDE4A69@mail.listserv.gmd.de>; Mon, 12 Feb 2001 21:58:18 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489134 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 12 Feb 2001 21:58:22 +0100 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 VAA19514 for ; Mon, 12 Feb 2001 21:58:20 +0100 (MET) 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 VAA31962 for ; Mon, 12 Feb 2001 21:58:19 +0100 Received: from venus.open.ac.uk (venus.open.ac.uk [137.108.143.2]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1CKwIu10790 for ; Mon, 12 Feb 2001 21:58:18 +0100 (MET) Received: from fell.open.ac.uk by venus.open.ac.uk via SMTP Local (Mailer 3.1) with ESMTP; Mon, 12 Feb 2001 20:58:17 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.9.3+Sun/8.9.1) id UAA19441; Mon, 12 Feb 2001 20:58:31 GMT In-Reply-To: <14982.45082.150652.74719@istrati.zdv.uni-mainz.de> References: <200102091445.JAA00482@plmsc.psu.edu> <200102091643.RAA23818@mozart.ujf-grenoble.Fr> <14980.23750.628032.305093@gargle.gargle.HOWL> <14982.45082.150652.74719@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: VM 6.76 under Emacs 20.7.1 X-Authentication-Warning: fell.open.ac.uk: car2 set sender to car2@fell.open.ac.uk using -f Content-class: urn:content-classes:message Subject: Re: LaTeX's internal char representation (UTF8 or Unicode?) Date: Mon, 12 Feb 2001 21:58:30 +0100 Message-ID: <14984.20086.524553.168238@fell.open.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Chris Rowley" 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: 3866 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09536.8BA51B80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is going right back to Frank's original posting. > I'm saying LaTeX's not TeX's, mind. This is VERY important. > TeX is 7bit with a parser that accepts 8bit but doesn't by default = gives it > any meaning. On the other hand Omega is 16bit (or more these days?) = and could > be viewed as internally using something like Unicode for = representation. I think that this may be misleading if it is taken to imply that TeX has such an `internal representation'; I do not think that TeX has one = and I think that the fundamental designer of TeX does not support the concept of having one. It would be useful to know whether Omega's designers intend it to have = one. But in order not to confuse myself any further I want to stop talking about `internal languages'... real soon now:-). Although it was not explicit in the development of LaTeX's `internal representation' I think that the way its developers now see it is better described as an attempt, within the limitations of an efficient use of TeX's capabilities, to provide support for manipulation and reasoning about text at a useful level of abstraction. I therefore want to talk about and ask questions about a TRM =3D=3D Text string Representation for Reasoning and Manipulation = thing. This is a thing that enables a computer-based system for processing `text' to represent `text things' so that it can, easily and independently, do at least the following (not formal definitions): -- apply transformations to `text strings'; -- reason about `text strings'; -- construct more concrete representations of `text strings' as `relatively positioned unrendered graphical objects'; -- reason about such representations of text strings. A TRM is none of the following (although for efficiency of implementation it may well be closely related to them): -- a coding for `text files' (such as utf8 or ASCII); -- an encoding for strings of unrendered glyphs (such as the `text strings' in a dvi file or pdf file); -- an alphabet for information storage (such as the abstract alphabet for an XML document); -- a language for describing any actions (such as the contents of a TeX input file). I can now ask the following questions: Do the designers of Omega think that it needs or has a TRM? Do the designers of LaTeX-for-Omega think that it needs a TRM? chris ------_=_NextPart_001_01C09536.8BA51B80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: LaTeX's internal char representation (UTF8 or = Unicode?)

This is going right back to Frank's original = posting.

> I'm saying LaTeX's not TeX's, mind.

This is VERY important.

> TeX is 7bit with a parser that accepts 8bit but = doesn't by default gives it
> any meaning. On the other hand Omega is 16bit = (or more these days?) and could
> be viewed as internally using something like = Unicode for representation.

I think that this may be misleading if it is taken to = imply that TeX
has such an `internal representation'; I do not think = that TeX has one and I
think that the fundamental designer of TeX does not = support the
concept of having one.

It would be useful to know whether Omega's designers = intend it to have one.

But in order not to confuse myself any further I want = to stop talking
about `internal languages'... real soon = now:-).

Although it was not explicit in the development of = LaTeX's `internal
representation' I think that the way its developers = now see it is better
described as an attempt, within the limitations of an = efficient use of
TeX's capabilities, to provide support for = manipulation and reasoning
about text at a useful level of abstraction.


I therefore want to talk about and ask questions about = a
TRM =3D=3D Text string Representation for Reasoning = and Manipulation thing.

This is a thing that enables a computer-based system = for processing
`text' to represent `text things' so that it can, = easily and
independently, do at least the following (not formal = definitions):

-- apply transformations to `text strings';

-- reason about `text strings';

-- construct more concrete representations of `text = strings' as
   `relatively positioned unrendered = graphical objects';

-- reason about such representations of text = strings.


A TRM is none of the following (although for = efficiency of
implementation it may well be closely related to = them):

-- a coding for `text files' (such as utf8 or = ASCII);

-- an encoding for strings of unrendered glyphs (such = as the `text
   strings' in a dvi file or pdf = file);

-- an alphabet for information storage (such as the = abstract alphabet
   for an XML document);

-- a language for describing any actions (such as the = contents of a
   TeX input file).


I can now ask the following questions:

Do the designers of Omega think that it needs or has a = TRM?

Do the designers of LaTeX-for-Omega think that it = needs a TRM?


chris

------_=_NextPart_001_01C09536.8BA51B80--