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
Condense Mail Headers

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

Print Reply
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Frank Mittelbach <[log in to unmask]>
Date:
Sat, 17 Feb 2001 16:22:49 +0100
In-Reply-To:
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (59 lines)
some shorter answers to Javier's mail:

 > [Marcel:]
 > >  > Anyway, Frank, I just got your last mail in my inbox (need to read the
 > >  > details more carefully), and I think we agree that it's worth
 > >  > exploring if there would be a substantial advantage for having some
 > >  > engine with Unicode internal reprentation.
 > > [Frank:]
 > > it surely is, though i'm not convinced that the time has come, given that the
 > > current LICR actually is as powerful (or more powerful in fact) than unicode
 > > ever can be.
 >
 > Please, could you explain why?

I mean that the LICR is (conceptually) a superset of unicode; it can encode
any unicode character but also can encode characters not in unicode. Clearly
you can do that in Omega as well, but my point is that the LICR is invariant
to certain operations, eg writing to files and reading back in.


 > PS. I would also apologize for discussing a set of macros which
 > has not been made public yet, but remember it's only a

i see no grounds for the need to apologize here since you are discussing the
basic concepts of LaTeX and or how you think they could or need to bedeveloped
further (to, say, be usable with Omega)

 > draft and many thing are liable to change (and maybe
 > the final code can be quite different. As we Spaniards say,

if we would only discuss final code, that is not going to change, what should
we discuss, any why should we discuss it?

actually a large part your implementation should rather be discussed on this
list rather than on the omega developers list since it concerns derivation or
extensions to LaTeX's user interface --- that is if you (plural, ie the omega
developers) want to keep LaTeX compatible with a LaTeX variant on Omega

so i would really appreciate a discussion concerning its features and proposed
document interfaces on this list. clearly the actual implementation or details
very specific to Omega might not be that interesting, but how you model
language in the source and what kind of designer/user modifications are
possible etc are very interesting in general.

I can only repeat what i wrote to the developer list: if we go separate pathes
now and produce incompatible versions so that documents from LaTeXonTeX
can't be processed on LaTeXonOmega and vice versa[1] then this is hurting
everybody but mostly will have the danger of leaving Omega behind since the
majority of package that need to hook into language features will hook into
those provided by LaTeXonTeX since that has the bigger basis.

-------
[1] that direction is of course only possible if one doesn't use features of
omega not available in TeX but for many languages and documents it should and
would be possible to run on both systems (even if the output is slightly
different).

frank

ATOM RSS1 RSS2