Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Mar 2003 17:54:32 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h23GsT6C012599 for ; Mon, 3 Mar 2003 17:54:30 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.27]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h23GcNtt011137; Mon, 3 Mar 2003 17:38:23 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E1A5.8FE81400" Received: from listserv (listserv.uni-heidelberg.de [129.206.100.27]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h22N02JK028997; Mon, 3 Mar 2003 17:29:19 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 9060 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 3 Mar 2003 17:29:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h23GTJ2k008893 for ; Mon, 3 Mar 2003 17:29:19 +0100 Received: from mercury.open.ac.uk (mercury.open.ac.uk [137.108.128.150]) by relay.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h23Gc9XM027417 for ; Mon, 3 Mar 2003 17:38:12 +0100 (MET) Received: from fell.open.ac.uk by mercury.open.ac.uk via SMTP Local (Mailer 3.1) with ESMTP; Mon, 3 Mar 2003 16:37:51 +0000 Received: (from car2@localhost) by fell.open.ac.uk (8.9.3+Sun/8.9.1) id QAA11403; Mon, 3 Mar 2003 16:37:27 GMT In-Reply-To: References: <630BE70C8320D6118D240002A589ABB204A95102@DERUM201> Return-Path: X-Mailer: VM 6.76 under Emacs 20.7.1 X-OriginalArrivalTime: 03 Mar 2003 16:54:32.0229 (UTC) FILETIME=[900B0550:01C2E1A5] X-Authentication-Warning: fell.open.ac.uk: car2 set sender to car2@fell.open.ac.uk using -f X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -1.5 () IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,X_AUTH_WARNING Content-class: urn:content-classes:message Subject: Re: Problem with baseline grid and multicol Date: Mon, 3 Mar 2003 17:37:26 +0100 Message-ID: A<15971.33990.991092.993962@fell.open.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Problem with baseline grid and multicol Thread-Index: AcLhpZApzuceXQrUSYit2GpwJxWXsg== From: "Chris Rowley" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4564 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E1A5.8FE81400 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > This needs not be related, but it sometimes leads to similar problems, = and > I haven't seen an explanation anywhere: why is \addvspace = discontinuous? The full algorithm for the case SKIP <=3D \lastskip is: > If > SKIP <=3D \lastskip < 0 or 0 <=3D SKIP <=3D \lastskip > then the net effect of \addvspace{SKIP} is to do nothing, > but if > SKIP < 0 <=3D \lastskip > then the net effect of \addvspace{SKIP} is that SKIP is added to the > current vertical list (thus moving everything up). > I never found any explanation of this algorithm, which comes from pre-2.09 LaTeX. The documentation in ltspaces.dtx contains some relevant comments on this and related problems with vertical spacing. For SKIP < 0, the discontinuity wrt \lastskip (at \lastkip =3D 0) always worried me but no one else has noticed it in 15 years, or so it seems. Note that when it is discontninuous it is, (IMO) worse, not even = monotone! It is clear from the original code and documentation that \addvspace is only intended to be used with itself (and \addpenalty); thus it was never designed to work with spaces resulting from low-level TeX commands or processes. Thus any non-zero value of \lastskip is assumed to have come from an \addvspace command (not a very wise assumtion, I agree). Also, it does say (note the first word): Extra vertical space is added by the command \addvspace{}. This implies that the PRE-CONDITION is perhaps that the argument (ie SKIP) is always positive. But then why put in the bizarre code at all? Isn't history fun? chris ------_=_NextPart_001_01C2E1A5.8FE81400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Problem with baseline grid and multicol

>
> This needs not be related, but it sometimes = leads to similar problems, and
> I haven't seen an explanation anywhere: why is = \addvspace discontinuous?

The full algorithm for the case  SKIP <=3D = \lastskip is:

> If
>   SKIP <=3D \lastskip < 0 or 0 = <=3D SKIP <=3D \lastskip
> then the net effect of \addvspace{SKIP} is to do = nothing,
> but if
>   SKIP < 0 <=3D \lastskip
> then the net effect of \addvspace{SKIP} is that = SKIP is added to the
> current vertical list (thus moving everything = up).
>

I never found any explanation of this algorithm, which = comes from
pre-2.09 LaTeX.  The documentation in = ltspaces.dtx contains some
relevant comments on this and related problems with = vertical spacing.

For SKIP < 0, the discontinuity wrt \lastskip (at = \lastkip =3D 0) always
worried me but no one else has noticed it in 15 = years, or so it seems.
Note that when it is discontninuous it is, (IMO) = worse, not even monotone!

It is clear from the original code and documentation = that \addvspace
is only intended to be used with itself (and = \addpenalty); thus it was
never designed to work with spaces resulting from = low-level TeX
commands or processes.

Thus any non-zero value of \lastskip is assumed to = have come from an
\addvspace command (not a very wise assumtion, I = agree).

Also, it does say (note the first word):

  Extra vertical space is added by the command = \addvspace{<skip>}.

This implies that the PRE-CONDITION is perhaps that = the argument (ie
SKIP) is always positive.  But then why put in = the bizarre code at all?

Isn't history fun?


chris

------_=_NextPart_001_01C2E1A5.8FE81400--