Article View: comp.text.tex
Article #327Bug in TeX's splitting routine??
From: Walter D. Neumann
Date: Wed, 22 Jul 1992 20:27
Date: Wed, 22 Jul 1992 20:27
103 lines
4685 bytes
4685 bytes
The TeX program seems to have bug in its routine for splitting
insertions. I would appreciate if some TeXpert can confirm my
analysis.
THE PROBLEM:
According to the BOOK (pp.123/124), TeX will try to fit
an insertion on the current page ("Steps 1,2,3" in the BOOK). If it
fails to fit, it will try to split the insertion ("Step 4" in the
BOOK), putting what it can fit on the current page and the rest on the
next. In particular, if the insertion has no possible break point, it
should be split at its start, effectively moving it to the next page.
However, the splitting step (Step 4) can fail. In the following
file test.tex, TeX finds an insertion 62pt long (a 50pt rule plus the
\bigskip added by the plain \topinsert macro) when it has 58pt left on
the current page. It should split it at its start, thus holding it
over for the next page, and continue putting subsequent text on the
current page. Instead, the log shows TeX splitting at the end of the
insertion, which is 4pt too big! After this, TeX's documented
behaviour leads to disaster:
It reduces the pagegoal by the insertion size (62pt) since it plans
to put the insertion on the current page. This would give an overfull
\vbox, 4pt too big. Since it cannot put more material on the current
page, it backs up to the breakpoint of least cost, which is BEFORE the
insertion, and outputs the page. Thus, the insertion is held over to
page 2 (as it should be), but nothing more is put on page 1, resulting
in an enormously underfull \vbox.
THE EXPLANATION:
TeX takes the 4pt of shrink in the \bigskip it has added inside the
insertion into account in looking for a split point in the insertion,
but then does not take this shrink into account in pagebreaking. The
bug will thus appear whenever TeX is asked to split an insertion that
will fit on the current page after subtracting its shrink. The program
TeX SHOULD NOT take shrink into account in seeking to split an insertion.
THE SOLUTION??
The only solution, short of correcting the program TeX, is to make
sure insertions NEVER have any shrink in them. Since Plain TeX puts
shrink into topinserts, this means correcting the Plain TeX macro. I
have updated the style "newinsert.tex", which corrected several
previously noticed bugs in Plain's insert routines, to include this
correction.
Version 1.2 of newinsert.tex is available by ftp on
shape.mps.ohio-state.edu in pub/osutex/OSUDEG/tools
------------test.tex-------------cut here-------------------------------
\tracingpages1
\vsize=92pt
Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi
Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi
Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi Hi
\topinsert \hrule height 50pt \endinsert
Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye Bye
Add as much extra text as you want here.
\bye
----------end of test.tex-------cut here--------------------------------
----------test.log------------------------------------------------------
This is TeX, C Version 3.14t3 (format=plain 91.8.16) 22 JUL 1992 10:53
**test
(test.tex
%% goal height=92.0, max depth=4.0
% t=10.0 g=92.0 b=10000 p=150 c=100000#
% t=22.0 g=92.0 b=10000 p=150 c=100000#
% split253 to 58.0,62.0 p=-10000
% t=34.0 g=30.0 b=* p=0 c=*
Underfull \vbox (badness 10000) has occurred while \output is active
\vbox(92.0+0.0)x469.75499
..etc.
[1]
%% goal height=92.0, max depth=4.0
% t=10.0 g=30.0 b=10000 p=0 c=100000#
% t=22.0 plus 1.0 g=30.0 b=10000 p=300 c=100000#
% t=34.0 plus 1.0 g=30.0 b=* p=0 c=*
[2]
%% goal height=92.0, max depth=4.0
% t=10.0 g=92.0 b=10000 p=0 c=100000#
% t=11.94444 plus 1.0fill g=92.0 b=0 p=-20000 c=-20000#
[3] )
Output written on test.dvi (3 pages, 744 bytes).
-----------end of test.log---------------------------------------------
--
Walter Neumann Email: neumann@mps.ohio-state.edu
Department of Mathematics neumann@ohstpy.bitnet
Ohio State University Tel: 614-292-4886 (office)
Columbus, OH 43210 -292-4975(Math. Dept.) -292-1479 (Dept. Fax)
Technical Details
Message-ID:
<9207222027.AA22118@brubeck.mps.ohio-state.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!wupost!sdd.hp.com!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!info-texShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!wupost!sdd.hp.com!usc!noiro.acs.uci.edu!unogate!mvb.saic.com!info-tex From: Walter D. Neumann <neumann@function.mps.ohio-state.edu> Newsgroups: comp.text.tex Subject: Bug in TeX's splitting routine?? Message-ID: <9207222027.AA22118@brubeck.mps.ohio-state.edu> Date: Wed, 22 Jul 92 16:27:53 EDT Organization: Info-Tex<==>Comp.Text.Tex Gateway X-Gateway-Source-Info: Mailing List Lines: 103