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=0pt
\multicolbaselineskip=0pt
\multicolovershoot=0pt
\multicolundershoot=0pt

> 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=587.80464, max depth=5.0          <----- this is 46x12dd
% t=10.0 g=1178.44939 b=10000 p=150 c=100000#    <----- \topskip
% t=22.8401 g=1178.44939 b=10000 p=150 c=100000# <----- \topskip+12dd
% t=35.6802 g=1178.44939 b=10000 p=0 c=100000#   <----- +12dd etc.
% t=61.36041 g=1178.44939 b=10000 p=0 c=100000#
% t=74.20052 g=1178.44939 b=10000 p=150 c=100000#<----- this is where
                                                        multicol ends
% t=87.04062 g=1178.44939 b=10000 p=0 c=100000#  <----- this is where

% t=99.88072 g=1178.44939 b=10000 p=0 c=100000#         the next line
% t=112.72083 g=1178.44939 b=10000 p=0 c=100000#        should be
% t=125.56093 g=1178.44939 b=10000 p=0 c=100000#
% t=138.40103 g=1178.44939 b=10000 p=150 c=100000#
% t=151.24113 g=1178.44939 b=10000 p=0 c=100000#
% t=165.66484 g=1178.44939 b=10000 p=0 c=100000#
% t=165.66484 g=1178.44939 b=10000 p=-10000 c=-10000#

Package multicol: Balance columns on input line 754:
Column 1 badness: 0
First column = 74.20052pt (74.20052pt) <> last column = 74.20052pt
Final badness: 0
[...]
%% goal height=587.80464, max depth=5.0
% t=0.0 g=587.80464 b=10000 p=0 c=100000#
% t=74.20052 g=587.80464 b=10000 p=0 c=100000#
% t=74.20052 g=587.80464 b=10000 p=0 c=100000#

Package multicol: Current page:
(multicol)        height=587.80464pt: used 74.20052pt ->
free=513.60413pt
(multicol)        needed 12.8401pt (for \postmulticols ) on input line
754.

Package multicol: Ending environment  on input line 754.

% t=89.85472 g=587.80464 b=10000 p=-300 c=100000#
^^^^^^^^^^^^
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