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