Thierry Bouche <[log in to unmask]> writes:
> Well, when i simply gently ask tex to do what seems the minimal
> requirements of quality typography by setting the parameters to \pm
> the values above, it appears that it can't do its job anymore, it
> stretchs infinitely my tiny vertical glue to find a page break, it
> removes up to 2 lines from a page because of widow/broken control,
For homogeneous text like in a novel, snapping to a grid may be
considered quality typography. For material with lots of odd-sized
objects such as equations or smaller-typesize quotes or section heads,
snapping to a grid can easily lead to vertical spacing that looks
worse than the usual TeX approach. Let L = line spacing, e = smallest
unit of space that forces use of an extra grid line, then what do you
think this sequence looks like?
equation (height L+e)
equation (height L)
equation (height L+e)
That's right, the visible whitespace around the equations fluctuates
up and down by almost .5L in the same page. For a typical L of 12pt
this is 6pt.
So grid-snapping is not "quality typography" for such material. (Since
the material that I usually work with has lots of displayed equations
and other odd-sized elements, I have never had sufficient reason to
work on a grid-based system of vertical spacing.)
But if you assume that all lines are normal height and all vertical
spaces are integral multiples of baselineskip, a grid-based system is
easy. However ... if you also want automatic widow/orphan suppression
*and* flush-bottom columns then you are talking about mutually
conflicting constraints which are hard for any system, not just
LaTeX. Most publishers just have human beings fixing the more
difficult page breaks "by hand".
Otherwise you need to plug in a different LaTeX output routine that
holds more of the pages in memory while seeking page breaking
solutions. The current one as you probably know ships out each page as
soon as a locally optimum page break is found.
Historically there has not been much leeway to work on such output
routines because two or three complex pages (plus, perhaps, some
pending figures) can use up 256K of main memory and there is no way to
have the output routine check the current memory usage to decide if
there is enough room to consider more material. Lacking such a check,
an output routine that considers two pages or four pages at a time
instead of one is much more likely to create problems by simply
failing in the middle of a job with a fatal TeX out-of-memory error
and leaving an incomplete .dvi file.
If you want to handle floating objects like footnotes, figures,
tables, the algorithm can easily become infinitely complicated.
I think it would be interesting to try to handle four pages at a time
(two two-page spreads; try to optimize the first one with the ability
to borrow lines from the second one). But I don't think I would want
to go beyond that.