LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Chris Rowley <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Mon, 12 Feb 2001 20:58:30 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
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 == 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

ATOM RSS1 RSS2