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 f1HHDBf02931 for ; Sat, 17 Feb 2001 18:13:11 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1HHDBd19997 . for ; Sat, 17 Feb 2001 18:13:11 +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 f1HHDAQ03974 for ; Sat, 17 Feb 2001 18:13:10 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09904.E78BED80" 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 SAA26197 for ; Sat, 17 Feb 2001 18:13:09 +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 f1HHD9H19769 for ; Sat, 17 Feb 2001 18:13:09 +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 <3.B80A9D56@mail.listserv.gmd.de>; Sat, 17 Feb 2001 18:12:57 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 489560 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sat, 17 Feb 2001 18:13:01 +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 SAA22539 for ; Sat, 17 Feb 2001 18:13:00 +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 SAA51122 for ; Sat, 17 Feb 2001 18:13:01 +0100 Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f1HHD2x18536 for ; Sat, 17 Feb 2001 18:13:02 +0100 (MET) Received: from [195.20.224.209] (helo=mrvdom02.schlund.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14UAur-0001mb-00 for LATEX-L@urz.uni-heidelberg.de; Sat, 17 Feb 2001 18:13:01 +0100 Received: from manz-3e36483b.pool.mediaways.net ([62.54.72.59] helo=istrati.zdv.uni-mainz.de) by mrvdom02.schlund.de with esmtp (Exim 2.12 #2) id 14UAvO-00052V-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sat, 17 Feb 2001 18:13:35 +0100 Received: (from latex3@localhost) by istrati.zdv.uni-mainz.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id SAA06063; Sat, 17 Feb 2001 18:10:18 +0100 In-Reply-To: <14985.27933.205182.551235@gargle.gargle.HOWL> References: <200102131655.QAA05656@penguin.nag.co.uk> <14985.27933.205182.551235@gargle.gargle.HOWL> Return-Path: X-Mailer: VM 6.75 under Emacs 20.4.1 X-Authentication-Warning: istrati.zdv.uni-mainz.de: latex3 set sender to frank@mittelbach-online.de using -f Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary Date: Sat, 17 Feb 2001 18:10:18 +0100 Message-ID: <14990.45178.192666.234476@istrati.zdv.uni-mainz.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Frank Mittelbach" 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: 3955 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09904.E78BED80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Marcel Oliver wrote: > David, some question for clarification: since I can't find his answers here are mine (and he can disagree with = me:-) > David Carlisle writes: > > If latex switched to use omega (only) then > > a) this might require omega to be more stable than omega users = would > > wish, ie it might prematurely limit addition of new features. > > - Is the envisioned time frame for Omega to stabilize really longer = than > a realistic time frame for LaTeX3 to be completed? probably not, but you can't build on something if it changes below you = (or at least that is pretty difficult). > > b) it would cut out people using tex systems that don't include = omega. > > You might say they should all switch to web2c tex, but that's like > > saying that everyone should use emacs on linux. Clearly it's true, = but > > it doesn't happen that way. > > - What are the platforms that can compile TeX but cannot compile > Omega? it's not only the question of the platform it is also the question of = the system (eg the commercial ones). While I don't think this is really = important if you come up with good reasons for changing so that the people on free distributions change it is a factor not to overlook. > > c) special case of (b) it would (at present, I think) cut out = pdflatex. > > - How much of an advantage is pdftex compared to creating pdf via = DVI? > I have only done the latter without any problems, but of course it > involves more file format conversions. not only that, but "rich" as produced via pdftex with hyperef might be = more difficult to provide (I might get corrected here), eg can you easily = produce references etc via the dvi -> ps -> pdf route right now? that might = become a non issue but I guess there is an advantage when you can control what is produced for the target format directly. > > d) It would require reasonably major surgery to LaTeX internals. = It > > Now it's getting interesting... > > - Is it basically clear to the LaTeX experts what needs to be done, = or > will major conceptual work be necessary? difficult to say. this partly depends on the underlying features you = finally build upon. See our discussion of LICR viz OICR1/2. while I consider = Omega far ahead of TeX in what ocps can be used for, they operate on OICR2 while = there isn't enough control for OICR1 which is sort of the equivalent of LICR. = So LaTeX right now is ahead there and finding concepts that work on top of = the current Omega model, would be difficult. That might vanish if the model = is changed in this respect. > - How do such changes compare with what is being done anyway for > LaTeX3? for a lot of areas where we try to make progress for LaTeX3 Omega = doesn't concern itself with, so we would struggle there as well as within the = bounds of TeX. eTeX has a few items that would help but eTeX as now isn't an = engine you could build upon > - Will things get harder or easier with Omega? neither, as of now, essentially just different in a few areas > > would be possible to make documents and packages using "documented > > interfaces" still work with a new internal character handling, but > > ctan will reveal a lot of heavily used packages that for good (or = bad) > > reasons don't use documented interfaces, but just redefine = arbitrary > > macros. (Often because there isn't a documented interface). > > A lot of these would break. > > Again, it may be good to assess the extent of potential damage. The > switch to 2e has broken lots of stuff, but in the long run it was the > right thing to do. So one should make a strong case why it should be > otherwise now. (And maybe some packages actually deserve to die...) actually most stuff did work after the switch from 209 to 2e, but i = expect more things to not work after a switch from 2e to X I personally think that that switch needs to be accompanied by a heavy organised rewrite of external packages (perhaps even by financially = supported rewrite initially) > > So in short to medium term it seems there have to be two versions > > latex/omega and latex/tex. How compatible they can be as = latex/omega > > uses more omega features I am not sure. > > This is a situation we should REALLY avoid! you can't at this stage avoid the fact that Omega can do things that TeX = can't just like pdftex or etex can do things TeX and Omega can't do. And some of the things Omega can do require kernel level internal bits = being implemented quite differently. as long as such features are kept at bay (eg pdftex features are = essentially hidden by the package hyperef) the situation is relatively relaxed, ie documents not using \usepackage[pdf]{hyperref} can run on LaTeX based on = TeX, etc. But the moment you start providing alternate syntax for the source = document you end up making perfectly valid document sources impossible to use = with different LaTeX implementation and that creates very unnecesary islands. = This is comparable to producing a document class that is essentially encoding = the functionality of article.cls but changing \section \subsection etc to \begin{heading}. frank ------_=_NextPart_001_01C09904.E78BED80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary

Marcel Oliver wrote:
 > David, some question for = clarification:

since I can't find his answers here are mine (and he = can disagree with me:-)

 > David Carlisle writes:
 >  > If latex switched to use omega = (only) then
 >  > a) this might require omega to = be more stable than omega users would
 >  > wish, ie it might prematurely = limit addition of new features.
 >
 > - Is the envisioned time frame for Omega = to stabilize really longer than
 >   a realistic time frame for = LaTeX3 to be completed?

probably not, but you can't build on something if it = changes below you (or at
least that is pretty difficult).

 >  > b) it would cut out people using = tex systems that don't include omega.
 >  > You might say they should all = switch to web2c tex, but that's like
 >  > saying that everyone should use = emacs on linux. Clearly it's true, but
 >  > it doesn't happen that = way.
 >
 > - What are the platforms that can compile = TeX but cannot compile
 >   Omega?

it's not only the question of the platform it is also = the question of the
system (eg the commercial ones). While I don't think = this is really important
if you come up with good reasons for changing so that = the people on free
distributions change it is a factor not to = overlook.

 >  > c) special case of (b) it would = (at present, I think) cut out pdflatex.
 >
 > - How much of an advantage is pdftex = compared to creating pdf via DVI?
 >   I have only done the latter = without any problems, but of course it
 >   involves more file format = conversions.

not only that, but "rich" as produced via = pdftex with hyperef might be  more
difficult to provide (I might get corrected here), eg = can you easily produce
references etc via the dvi -> ps -> pdf route = right now? that might become a
non issue but I guess there is an advantage when you = can control what is
produced for the target format directly.


 >  > d) It would require reasonably = major surgery to LaTeX internals. It
 >
 > Now it's getting interesting...
 >
 > - Is it basically clear to the LaTeX = experts what needs to be done, or
 >   will major conceptual work be = necessary?

difficult to say. this partly depends on the = underlying features you finally
build upon. See our discussion of LICR viz OICR1/2. = while I consider Omega far
ahead of TeX in what ocps can be used for, they = operate on OICR2 while there
isn't enough control for OICR1 which is sort of the = equivalent of LICR. So
LaTeX right now is ahead there and finding concepts = that work on top of the
current Omega model, would be difficult. That might = vanish if the model is
changed in this respect.

 > - How do such changes compare with what is = being done anyway for
 >   LaTeX3?

for a lot of areas where we try to make progress for = LaTeX3 Omega doesn't
concern itself with, so we would struggle there as = well as within the bounds
of TeX. eTeX has a few items that would help but eTeX = as now isn't an engine
you could build upon

 > - Will things get harder or easier with = Omega?

neither, as of now, essentially just different in a = few areas

 >  > would be possible to make = documents and packages using "documented
 >  > interfaces" still work = with a new internal character handling, but
 >  > ctan will reveal a lot of = heavily used packages that for good (or bad)
 >  > reasons don't use documented = interfaces, but just redefine arbitrary
 >  > macros. (Often because there = isn't a documented interface).
 >  > A lot of these would = break.
 >
 > Again, it may be good to assess the extent = of potential damage.  The
 > switch to 2e has broken lots of stuff, but = in the long run it was the
 > right thing to do.  So one should = make a strong case why it should be
 > otherwise now.  (And maybe some = packages actually deserve to die...)

actually most stuff did work after the switch from 209 = to 2e, but i expect
more things to not work after a switch from 2e to = X

I personally think that that switch needs to be = accompanied by a heavy
organised rewrite of external packages (perhaps even = by financially supported
rewrite initially)


 >  > So in short to medium term it = seems there have to be two versions
 >  > latex/omega and latex/tex. How = compatible they can be as latex/omega
 >  > uses more omega features I am = not sure.
 >
 > This is a situation we should REALLY = avoid!

you can't at this stage avoid the fact that Omega can = do things that TeX can't
just like pdftex or etex can do things TeX and Omega = can't do.
And some of the things Omega can do require kernel = level internal bits being
implemented quite differently.

as long as such features are kept at bay (eg pdftex = features are essentially
hidden by the package hyperef) the situation is = relatively relaxed, ie
documents not using \usepackage[pdf]{hyperref} can = run on LaTeX based on TeX,
etc.

But the moment you start providing alternate syntax = for the source document
you end up making perfectly valid document  = sources impossible to use with
different LaTeX implementation and that creates very = unnecesary islands. This
is comparable to producing a document class that is = essentially encoding the
functionality of article.cls but changing \section = \subsection etc to
\begin{heading}.

frank

------_=_NextPart_001_01C09904.E78BED80--