Received: via tmail-4.1(11) (invoked by user schoepf) for schoepf; Mon, 31 Jan 2000 18:13:50 +0100 (MET) Received: from mailgate2.zdv.Uni-Mainz.DE (mailgate2.zdv.Uni-Mainz.DE [134.93.8.57]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id SAA29240 for ; Mon, 31 Jan 2000 18:13:49 +0100 (MET) MIME-Version: 1.0 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate2.zdv.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id SAA16432 for ; Mon, 31 Jan 2000 18:13:48 +0100 (MET) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6C0E.8A949B00" Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <15.508EA650@mail.listserv.gmd.de>; Mon, 31 Jan 2000 18:13:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 449904 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 31 Jan 2000 18:12:02 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id SAA11197 for ; Mon, 31 Jan 2000 18:12:01 +0100 (MET) Received: from sun06 (sun06.ams.org [130.44.1.6]) by relay.uni-heidelberg.de (8.9.3+Sun/8.9.3) with ESMTP id SAA16795 for ; Mon, 31 Jan 2000 18:11:59 +0100 (MET) Received: from sun06.ams.org by sun06.ams.org (PMDF V5.1-10 #27147) id <0FP700402MIFR5@sun06.ams.org> for LATEX-L@URZ.UNI-HEIDELBERG.DE; Mon, 31 Jan 2000 12:13:27 -0500 (EST) In-Reply-To: Frank Mittelbach's message of Thu, 27 Jan 2000 23:21:08 +0100 Lines: 33 References: <200001272221.XAA00635@istrati.zdv.uni-mainz.de> Return-Path: X-Mailer: Gnus v5.5/Emacs 20.2 x-vm-v5-data: ([nil nil nil nil nil nil nil nil nil]["1659" "Mon" "31" "January" "2000" "12:13:27" "-0500" "Michael J. Downes" "mjd@AMS.ORG" nil "33" "Re: templates for galley formatting --- the basics" "^Date:" nil nil "1" nil nil nil nil nil]nil) Comments: Originally-From: Michael John Downes Content-class: urn:content-classes:message Subject: Re: templates for galley formatting --- the basics Date: Mon, 31 Jan 2000 18:13:27 +0100 Message-ID: <200001311711.SAA16795@relay.uni-heidelberg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Michael J. Downes" 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: 3529 This is a multi-part message in MIME format. ------_=_NextPart_001_01BF6C0E.8A949B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable About \par: "it can't be successfully trapped by the macro programmer" It seems to me there are two related problems. 1. Blank line should execute \GalleyCleverPar, and the most important reason for this is to put in a nobreak penalty before a following parskip. If some package redefines \par directly without awareness of \GalleyCleverPar, this is lost. 2. The well-known infinite loop problem. For 1, let's assume that the package that redefined par managed to redefine it in such a way that it succeeds at least in switching to vmode. (If not, then we are in case 2.) Then we are either at the end of a box, or some additional material will follow on the same vertical list. In the end of box case the situation is probably OK without further work? And when additional material follows it will always be the special internal galley code from \everypar, which can check for some special flag that indicates GalleyCleverPar was called? Checking \lastpenalty would probably be ideal. Ah let's see, no unfortunately the parskip gets in the way (and is not removable if we are on the MVL). So probably have to use either prevdepth or prevgraf to communicate information. Have \GalleyCleverPar set \prevgraf to some absurd value (such as maxint). Then you can check prevgraf to see if the last par was a GalleyCleverPar or a not-so-clever par. Also if we are attempting to make a big step toward LaTeX 3 at this point what about \catcode\endlinechar=3D10 and require explicit markup (\p, \para, \endpara?) instead of blank lines. I seem to recall from earlier LaTeX 3 discussions that this appeared to be a necessary step sooner or later for other reasons. ------_=_NextPart_001_01BF6C0E.8A949B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: templates for galley formatting --- the basics

About \par: "it can't be successfully trapped by = the macro programmer"

It seems to me there are two related problems.

1. Blank line should execute \GalleyCleverPar, and the = most important
reason for this is to put in a nobreak penalty before = a following
parskip. If some package redefines \par directly = without awareness of
\GalleyCleverPar, this is lost.

2. The well-known infinite loop problem.

For 1, let's assume that the package that redefined = par managed to
redefine it in such a way that it succeeds at least = in switching to
vmode. (If not, then we are in case 2.)

Then we are either at the end of a box, or some = additional material will
follow on the same vertical list. In the end of box = case the situation
is probably OK without further work? And when = additional material
follows it will always be the special internal galley = code from
\everypar, which can check for some special flag that = indicates
GalleyCleverPar was called? Checking \lastpenalty = would probably be
ideal. Ah let's see, no unfortunately the parskip = gets in the way (and
is not removable if we are on the MVL). So probably = have to use either
prevdepth or prevgraf to communicate information. = Have \GalleyCleverPar
set \prevgraf to some absurd value (such as maxint). = Then you can check
prevgraf to see if the last par was a GalleyCleverPar = or a not-so-clever
par.

Also if we are attempting to make a big step toward = LaTeX 3 at this
point what about \catcode\endlinechar=3D10 and = require explicit markup
(\p, \para, \endpara?) instead of blank lines. I seem = to recall from
earlier LaTeX 3 discussions that this appeared to be = a necessary step
sooner or later for other reasons.

------_=_NextPart_001_01BF6C0E.8A949B00--