Received: from mail.proteosys.com ([62.225.9.49]) by nummer-3.proteosys with Microsoft SMTPSVC(5.0.2195.5329); Mon, 3 Mar 2003 15:18:36 +0100 Received: by mail.proteosys.com (8.12.2/8.12.2) with ESMTP id h23EIX6C012156 for ; Mon, 3 Mar 2003 15:18:34 +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 h23E2dtt027785; Mon, 3 Mar 2003 15:02:39 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E18F.C74BC600" 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 h22N02EE028997; Mon, 3 Mar 2003 14:52:54 +0100 Received: from LISTSERV.UNI-HEIDELBERG.DE by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8d) with spool id 8775 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 3 Mar 2003 14:52:54 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.12.2/8.12.2/SuSE Linux 0.6) with ESMTP id h23Dqr2k007127 for ; Mon, 3 Mar 2003 14:52:53 +0100 Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [212.227.126.252]) by relay2.uni-heidelberg.de (8.12.4/8.12.4) with ESMTP id h23E1jtt027581 for ; Mon, 3 Mar 2003 15:01:46 +0100 (MET) Received: from [212.227.126.223] (helo=mrvdomng.kundenserver.de) by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1) id 18pqVk-0001YY-00 for LATEX-L@listserv.uni-heidelberg.de; Mon, 03 Mar 2003 15:01:44 +0100 Received: from [80.128.36.135] (helo=DOMINUS) by mrvdomng.kundenserver.de with esmtp (Exim 3.35 #1) id 18pqVk-0001bu-00 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 03 Mar 2003 15:01:44 +0100 In-Reply-To: <630BE70C8320D6118D240002A589ABB204A95102@DERUM201> Organization: Art & Satz Return-Path: X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft Exchange V6.5 X-OriginalArrivalTime: 03 Mar 2003 14:18:36.0407 (UTC) FILETIME=[C789E070:01C2E18F] x-mime-autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id h23Dqr2k007128 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: -0.7 () IN_REP_TO,NOSPAM_INC,QUOTED_EMAIL_TEXT,SPAM_PHRASE_03_05 Content-class: urn:content-classes:message Subject: Re: Problem with baseline grid and multicol Date: Mon, 3 Mar 2003 15:01:40 +0100 Message-ID: A<000e01c2e18d$6a5f6430$657ba8c0@DOMINUS> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Problem with baseline grid and multicol Thread-Index: AcLhj8emx8+lHNV9TcapmS/Q4WY1cQ== From: "Ulrich Dirr" To: Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 4561 This is a multi-part message in MIME format. ------_=_NextPart_001_01C2E18F.C74BC600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank Mittelbach wrote: > i don't find it very surprising that at this stage the new OR is not > working fully with arbitrary packages. I guess however, that David > Kastrup would be interested in hearing about specific problems with > minimal example files (involving only one or two such packages). Of course I didn't suspect OR to work but was tempted to get it work. Not only because of the new concept but because of the grid balancing. ;-) > anyway, i understand the reminder of your mail as follows (correct me > if i'm wrong): you tried to produce grid based typesetting using std > latex2e + multicol doing this by setting various spacing parameters > so that they fall onto an imaginary grid. Yes. > well first of all \multicolovershoot/undershoot was a somewhat > rubbish idea i guess and in fact i finally decided to change the > default of one of them (overshoot) back to 0pt even though that means > an incompatible change. I have set: \multicolsep=3D0pt \multicolbaselineskip=3D0pt \multicolovershoot=3D0pt \multicolundershoot=3D0pt > the problem results from the fact that if you have only normal text > (no stretching etc) a positive \multicolovershoot can fool multicols > into thinking that n*\baselinskip-\multicolovershoot is a valid > column height. if you look through the recent bug reports on latex > tools (something 3400+) you should find a dicussion on that topic. > > there is however another space being incorrectly added by multicols > which is 1pt of \lineskip in certain situations. i will send you a > new multicols beta fixing all that off-line. This would be great. One point Excerpt of log file: %% goal height=3D587.80464, max depth=3D5.0 <----- this is = 46x12dd % t=3D10.0 g=3D1178.44939 b=3D10000 p=3D150 c=3D100000# <----- = \topskip % t=3D22.8401 g=3D1178.44939 b=3D10000 p=3D150 c=3D100000# <----- = \topskip+12dd % t=3D35.6802 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# <----- +12dd = etc. % t=3D61.36041 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# % t=3D74.20052 g=3D1178.44939 b=3D10000 p=3D150 c=3D100000#<----- this = is where multicol ends % t=3D87.04062 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# <----- this = is where % t=3D99.88072 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# the = next line % t=3D112.72083 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# should = be % t=3D125.56093 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# % t=3D138.40103 g=3D1178.44939 b=3D10000 p=3D150 c=3D100000# % t=3D151.24113 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# % t=3D165.66484 g=3D1178.44939 b=3D10000 p=3D0 c=3D100000# % t=3D165.66484 g=3D1178.44939 b=3D10000 p=3D-10000 c=3D-10000# Package multicol: Balance columns on input line 754: Column 1 badness: 0 First column =3D 74.20052pt (74.20052pt) <> last column =3D 74.20052pt Final badness: 0 [...] %% goal height=3D587.80464, max depth=3D5.0 % t=3D0.0 g=3D587.80464 b=3D10000 p=3D0 c=3D100000# % t=3D74.20052 g=3D587.80464 b=3D10000 p=3D0 c=3D100000# % t=3D74.20052 g=3D587.80464 b=3D10000 p=3D0 c=3D100000# Package multicol: Current page: (multicol) height=3D587.80464pt: used 74.20052pt -> free=3D513.60413pt (multicol) needed 12.8401pt (for \postmulticols ) on input line 754. Package multicol: Ending environment on input line 754. % t=3D89.85472 g=3D587.80464 b=3D10000 p=3D-300 c=3D100000# ^^^^^^^^^^^^ But this value I don't understand. The next n\baselineskip value should be 87.04062 (see above; difference 2.8141pt). And curiously in the resulting output the next line of text is offset by ~0.4mm. When putting some \vspace command before the next line of text to compensate for this -- which is not what I want because I then have to do this very often and by hand -- I got the irritating behavior that this text line "oscillates" above and below the baseline when I'm changing the amount of vspace only a bit ... My first thought was to has something to do with the depth of the last line of the multicols environment. But this is not true. Then I thought that the value of \page@free is maybe irritating because 513.60413pt should be actually 510.76404pt (40x12dd); difference is 2.84009pt. Ulrich ------_=_NextPart_001_01C2E18F.C74BC600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Problem with baseline grid and multicol

Frank Mittelbach wrote:
> i don't find it very surprising that at this = stage the new OR is not
> working fully with arbitrary packages. I guess = however, that David
> Kastrup would be interested in hearing about = specific problems with
> minimal example files (involving only one or two = such packages).

Of course I didn't suspect OR to work but was tempted = to get it work.
Not only because of the new concept but because of = the grid balancing.
;-)

> anyway, i understand the reminder of your mail as = follows (correct me
> if i'm wrong): you tried to produce grid based = typesetting using std
> latex2e + multicol doing this by setting various = spacing parameters
> so that they fall onto an imaginary grid.

Yes.

> well first of all \multicolovershoot/undershoot = was a somewhat
> rubbish idea i guess and in fact i finally = decided to change the
> default of one of them (overshoot) back to 0pt = even though that means
> an incompatible change.

I have set:
\multicolsep=3D0pt
\multicolbaselineskip=3D0pt
\multicolovershoot=3D0pt
\multicolundershoot=3D0pt

> the problem results from the fact that if you = have only normal text
> (no stretching etc) a positive = \multicolovershoot can fool multicols
> into thinking that = n*\baselinskip-\multicolovershoot is a valid
> column height. if you look through the recent = bug reports on latex
> tools (something 3400+) you should find a = dicussion on that topic.
>
> there is however another space being incorrectly = added by multicols
> which is 1pt of \lineskip in certain situations. = i will send you a
> new multicols beta fixing all that = off-line.

This would be great. One point

Excerpt of log file:
%% goal height=3D587.80464, max = depth=3D5.0          = <----- this is 46x12dd
% t=3D10.0 g=3D1178.44939 b=3D10000 p=3D150 = c=3D100000#    <----- \topskip
% t=3D22.8401 g=3D1178.44939 b=3D10000 p=3D150 = c=3D100000# <----- \topskip+12dd
% t=3D35.6802 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#   <----- +12dd etc.
% t=3D61.36041 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#
% t=3D74.20052 g=3D1178.44939 b=3D10000 p=3D150 = c=3D100000#<----- this is where
          &nbs= p;            = ;            =             &= nbsp;        multicol ends
% t=3D87.04062 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#  <----- this is where

% t=3D99.88072 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#         the next = line
% t=3D112.72083 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#        should be
% t=3D125.56093 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#
% t=3D138.40103 g=3D1178.44939 b=3D10000 p=3D150 = c=3D100000#
% t=3D151.24113 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#
% t=3D165.66484 g=3D1178.44939 b=3D10000 p=3D0 = c=3D100000#
% t=3D165.66484 g=3D1178.44939 b=3D10000 p=3D-10000 = c=3D-10000#

Package multicol: Balance columns on input line = 754:
Column 1 badness: 0
First column =3D 74.20052pt (74.20052pt) <> = last column =3D 74.20052pt
Final badness: 0
[...]
%% goal height=3D587.80464, max depth=3D5.0
% t=3D0.0 g=3D587.80464 b=3D10000 p=3D0 = c=3D100000#
% t=3D74.20052 g=3D587.80464 b=3D10000 p=3D0 = c=3D100000#
% t=3D74.20052 g=3D587.80464 b=3D10000 p=3D0 = c=3D100000#

Package multicol: Current page:
(multicol)        = height=3D587.80464pt: used 74.20052pt ->
free=3D513.60413pt
(multicol)        = needed 12.8401pt (for \postmulticols ) on input line
754.

Package multicol: Ending environment  on input = line 754.

% t=3D89.85472 g=3D587.80464 b=3D10000 p=3D-300 = c=3D100000#
^^^^^^^^^^^^
But this value I don't understand. The next = n\baselineskip value should
be 87.04062 (see above; difference 2.8141pt).

And curiously in the resulting output the next line of = text is offset by
~0.4mm. When putting some \vspace command before the = next line of text
to compensate for this -- which is not what I want = because I then have
to do this very often and by hand -- I got the = irritating behavior that
this text line "oscillates" above and below = the baseline when I'm
changing the amount of vspace only a bit ...

My first thought was to has something to do with the = depth of the last
line of the multicols environment. But this is not = true. Then I thought
that the value of \page@free is maybe irritating = because 513.60413pt
should be actually 510.76404pt (40x12dd); difference = is 2.84009pt.

Ulrich

------_=_NextPart_001_01C2E18F.C74BC600--