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 f1BHo7H11769 for ; Sun, 11 Feb 2001 18:50:07 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f1BHo6d25788 . for ; Sun, 11 Feb 2001 18:50:06 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f1BHo1M06582 for ; Sun, 11 Feb 2001 18:50:01 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09453.11E83180" 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 SAA29768 for ; Sun, 11 Feb 2001 18:50:00 +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 f1BHnxM06574 for ; Sun, 11 Feb 2001 18:49:59 +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 <10.E191ABB3@mail.listserv.gmd.de>; Sun, 11 Feb 2001 18:49:52 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 487682 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Sun, 11 Feb 2001 18:49:55 +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 SAA23557 for ; Sun, 11 Feb 2001 18:49:53 +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 SAA33436 for ; Sun, 11 Feb 2001 18:49:54 +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 f1BHnsu20696 for ; Sun, 11 Feb 2001 18:49:54 +0100 (MET) Received: from [195.20.224.219] (helo=mrvdom03.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 14S0dF-0006Ov-00 for LATEX-L@urz.uni-heidelberg.de; Sun, 11 Feb 2001 18:49:53 +0100 Received: from manz-3e365955.pool.mediaways.net ([62.54.89.85] helo=istrati.zdv.uni-mainz.de) by mrvdom03.kundenserver.de with esmtp (Exim 2.12 #2) id 14S0d8-00068q-00 for LATEX-L@URZ.UNI-HEIDELBERG.DE; Sun, 11 Feb 2001 18:49:46 +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 RAA12165; Sun, 11 Feb 2001 17:46:46 +0100 In-Reply-To: References: <14982.39116.773341.877559@istrati.zdv.uni-mainz.de> 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: hyphenation morass Date: Sun, 11 Feb 2001 17:46:46 +0100 Message-ID: <14982.49654.241503.82704@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: 3801 This is a multi-part message in MIME format. ------_=_NextPart_001_01C09453.11E83180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > this does not mean that the source input can't be in a more = suitable encoding > > and my suggestion is to use the LaTeX internal character = representation here > > (and not UTF8) but in some sense either is similarily useful since = both > > describe in a unique way the set of characters and both can be = converted from > > one into the other. > > I would like to suggest UTF8. First of all, they would also be usable = with > Omega, and second, parsing UTF8 is easier than parsing LaTeX internal > character representation (LICR?). wrong answer :-) a) UTF8 isn't seasier to parse for LaTeX than LICR if the LICR is not = UTF8 that is :-) since LaTeX has the parser for LICR built in and for UTF8 = you have to add it b) LaTeX is independent of Omega and so you should be able to parse = LICR as well in Omega if Omega is running with LaTeX on top. now of course both are lies to some extend, so try again: - point a) above is not true if you plug something on top of LaTeX to = bypass its internal handling and replace it with something else, like part = of the language support for omega that is currently being worked on by = Javier. question however is whether this will lead in the long term to = anything useful for both sides --- i doubt it. - point b) depends on how Omega wants to make use of those patterns. = does it really use them at all? if so on what level do they act? i'm pleading ignorance here, so please tell me. I would have thought that the = pattern idea closely tied to font encodings as it is with TeX doesn't make = much sense for Omega. Or are they operate with the pattern on the unicode = level? if so nearly none of the patterns right now should be usable for = Omega. frank ps is there anybody at the other end of omega-developers-list being = interested on a unified version of LaTeX supporting omega and tex? as you may have = seen (since i know you are on it) i've written up a couple of comments and = ideas regarding Javiers drafts but was even more stonewalled than it sometimes happens on this list. ------_=_NextPart_001_01C09453.11E83180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: hyphenation morass

 > > this does not mean that the source = input can't be in a more suitable encoding
 > > and my suggestion is to use the LaTeX = internal character representation here
 > > (and not UTF8) but in some sense = either is similarily useful since both
 > > describe in a unique way the set of = characters and both can be converted from
 > > one into the other.
 >
 > I would like to suggest UTF8. First of = all, they would also be usable with
 > Omega, and second, parsing UTF8 is easier = than parsing LaTeX internal
 > character representation (LICR?).

wrong answer :-)

a) UTF8 isn't seasier to parse for LaTeX than LICR if = the LICR is not UTF8
that is :-) since LaTeX has the parser for LICR built = in and for UTF8 you have
to add it

b) LaTeX is independent of Omega  and so you = should be able to parse LICR as
well in Omega if Omega is running with LaTeX on = top.

now of course both are lies to some extend, so try = again:

 - point a) above is not true if you plug = something on top of LaTeX to bypass
   its internal handling and replace it = with something else, like part of the
   language support for omega that is = currently being worked on by Javier.
   question however is whether this will = lead in the long term to anything
   useful for both sides --- i doubt = it.

 - point b) depends on how Omega wants to make = use of those patterns. does it
   really use them at all? if so on what = level do they act? i'm pleading
   ignorance here, so please tell me. I = would have thought that the pattern
   idea closely tied to font encodings as = it is with TeX doesn't make much
   sense for Omega. Or are they operate = with the pattern on the unicode level?
   if so nearly none of the patterns right = now should be usable for Omega.

frank

ps is there anybody at the other end of = omega-developers-list being interested
on a unified version of LaTeX supporting omega and = tex? as you may have seen
(since i know you are on it) i've written up a couple = of comments and ideas
regarding Javiers drafts but was even more = stonewalled than it sometimes
happens on this list.

------_=_NextPart_001_01C09453.11E83180--