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 f4AJKvf06168 for ; Thu, 10 May 2001 21:20:57 +0200 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f4AJKu702009 . for ; Thu, 10 May 2001 21:20:56 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0D986.56B63280" 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 f4AJKtU13050 for ; Thu, 10 May 2001 21:20:55 +0200 (MET DST) 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 VAA09491 for ; Thu, 10 May 2001 21:20:55 +0200 (MEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 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 f4AJKsU13043 for ; Thu, 10 May 2001 21:20:54 +0200 (MET DST) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <2.595F150E@mail.listserv.gmd.de>; Thu, 10 May 2001 21:19:23 +0200 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 496196 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 10 May 2001 21:20:51 +0200 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 VAA08796 for ; Thu, 10 May 2001 21:20:50 +0200 (MET DST) 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 VAA32952 for ; Thu, 10 May 2001 21:20:50 +0200 Received: from smtp.wanadoo.es (m1smtpisp01.wanadoo.es [62.36.220.61] (may be forged)) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f4AJKoQ25283 for ; Thu, 10 May 2001 21:20:51 +0200 (MET DST) Received: from [62.36.81.128] (62-36-81-128.dialup.uni2.es [62.36.81.128]) by smtp.wanadoo.es (8.10.2/8.10.2) with ESMTP id f4AJKk729706 for ; Thu, 10 May 2001 21:20:46 +0200 (MET DST) Return-Path: X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Content-class: urn:content-classes:message Subject: Re: Multilingual Encodings Summary 2.2 Date: Thu, 10 May 2001 21:16:40 +0100 Message-ID: <200105101920.f4AJKk729706@smtp.wanadoo.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Javier Bezos" 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: 4044 This is a multi-part message in MIME format. ------_=_NextPart_001_01C0D986.56B63280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lars said: > As I understand the Omega draft documentation, there can be no more = than > one OTP (the \InputTranslation) acting on the input of LaTeX at any = time > and that OTP in only meant to handle the basic conversion from the = external > encoding (ASCII, latin-1, UTF-8, or whatever) to the internal 32-bit > Unicode. All this happens way before the input gets tokenized, so = there is > by the way no point in worrying about what the OTP should do with = control > sequences. > > The next time any OTP gets to act on the characters is when they are = being > put onto a horizontal list---this is where the OTPs can be stacked and = one > OTP can act on the output on another---i.e., in the first stage of = _output_ > from LaTeX. Yet these are what is described as "Input: set of input > conventions" (maybe because the Omega draft documentation calls them = "Input > filters") in the itemize-list on page 8!! (Note: I am not questioning > whether this is a correct summary of the debate---if I am questioning > anything it is rather the idea expressed in the original = contribution.) > Certainly there is a need for some OTPs to act on the text at this = stage, > but some of the processing should rather be done on the input side of = LaTeX > (for which the current Omega seems to provide very little). I note = that the I don't see the point of doing that. Processing information after full expansion is essentially LaTeX without inputenc and fontenc, and very = little code will be broken. Processing the source when it's read could break = lot of things. This means that auxiliary files will have different coding conventions and therefore differente processes should be applied = depending on the file to be read. I think that is an unnecessary complication. One of the problems here is if the code to be moved around should be processed first and then moved (like floats) or moved first and then processed (like marks). imo, the answer is definitely the second -- have you tried placing a caption of a figure in the outer margin of the page? (impossible without modifying the output routine because figures and captions are first boxed and then moved). As I said, preserving the original code when moving it around it's essential to avoid a mess, and in fact that is the very reason things are \protect'ed. This way, decisions could be taken depending on the final placement of the material (for example, should be a Japanese caption typeset vertically or horizontally?). Regards Javier ------_=_NextPart_001_01C0D986.56B63280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Multilingual Encodings Summary 2.2

Lars said:

> As I understand the Omega draft documentation, = there can be no more than
> one OTP (the \InputTranslation) acting on the = input of LaTeX at any time
> and that OTP in only meant to handle the basic = conversion from the external
> encoding (ASCII, latin-1, UTF-8, or whatever) to = the internal 32-bit
> Unicode. All this happens way before the input = gets tokenized, so there is
> by the way no point in worrying about what the = OTP should do with control
> sequences.
>
> The next time any OTP gets to act on the = characters is when they are being
> put onto a horizontal list---this is where the = OTPs can be stacked and one
> OTP can act on the output on another---i.e., in = the first stage of _output_
> from LaTeX. Yet these are what is described as = "Input: set of input
> conventions" (maybe because the Omega draft = documentation calls them "Input
> filters") in the itemize-list on page 8!! = (Note: I am not questioning
> whether this is a correct summary of the = debate---if I am questioning
> anything it is rather the idea expressed in the = original contribution.)
> Certainly there is a need for some OTPs to act = on the text at this stage,
> but some of the processing should rather be done = on the input side of LaTeX
> (for which the current Omega seems to provide = very little). I note that the

I don't see the point of doing that. Processing = information after full
expansion is essentially LaTeX without inputenc and = fontenc, and very little
code will be broken. Processing the source when it's = read could break lot
of things. This means that auxiliary files will have = different coding
conventions and therefore differente processes should = be applied depending
on the file to be read. I think that is an = unnecessary complication.

One of the problems here is if the code to be moved = around should be
processed first and then moved (like floats) or moved = first and then
processed (like marks). imo, the answer is definitely = the second --
have you tried placing a caption of a figure in the = outer margin
of the page? (impossible without modifying the output = routine because
figures and captions are first boxed and then moved). = As I said,
preserving the original code when moving it around = it's essential
to avoid a mess, and in fact that is the very reason = things are
\protect'ed. This way, decisions could be taken = depending on the
final placement of the material (for example, should = be a Japanese
caption typeset vertically or horizontally?).

Regards
Javier

------_=_NextPart_001_01C0D986.56B63280--