LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Classic View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender: Mailing list for the LaTeX3 project <[log in to unmask]>
From: "Michael J. Downes" <[log in to unmask]>
Date: Wed, 6 Jan 1999 08:47:33 -0500
In-Reply-To: Thierry Bouche's message of Tue, 05 Jan 1999 18:39:57 +0100
Comments: Resent-From: [log in to unmask] Originally-From: Michael John Downes <[log in to unmask]>
Reply-To: Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments: text/plain (72 lines)
Thierry Bouche <[log in to unmask]> writes:

> » 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.
>
> I don't agree. It is very easy to have section heading withs 1.5
> \baselineskip above, and .5 below, e.g. If you're using a multicolumn
> layout, facing lines that disagree are horrible _and_ disturbing.

I'm not sure I can agree. It seems that you are describing a merely
aesthetic view of the page from a distance, not something that
interferes with active reading (where you don't *want* to pay
attention to any columns other than the current column).

And there is more trouble unless you impose a restriction that section
titles cannot be more than one line long. Suppose your text is 10pt
with 13pt linespacing and suppose your section title font is 12pt.  In
order to keep to the grid with a two-line section title you are
required to use 13pt or 26pt linespacing for the title. Although I
suppose the natural answer is that your section heading macro must
count the lines and compute the amount of space needed to get back to
the grid (probably requires adjusting the space above the title to
match).

There is still more trouble when at the top of the left column you
have two lines of text followed by a section title, and in the right
column you have a section title at the very top. Now your .5
baselineskip is quite likely to miss the grid and if you modify the
space to reach the grid you have two section titles almost
side-by-side with noticeably different vertical spacing. Similar
scenarios occur if the designer wants to have extra .5 space
before/after a numbered list: what if you have two lists, one
beginning on page 4 and ending on page 5, the other entirely on page
5. Then snapping to a grid forces the two lists to have respectively
1.0 and 0.5 linespacing.

> What is very bad is TeX's behaviour of linespacing the lines with
> overhanging material (like integrals, badly formatted inline
> fractions...). I believe to be the responsability of the editors to
> "flatten" inline formulas, and display others.

Yes and no. Simple forcing to a grid is not the answer. What we need
for material with a lot of mathematics is a kind of skyline fitting
approach for deciding when lines need extra space. The system used by
the AMS before the switch to TeX always set text lines on the grid and
our production staff spent many hours fixing adjacent lines where a
second-order subscript in the first line collided with a second-order
superscript or accented capital letter in the second line, and things
like that.

> Also, It seems so obvious that double pages are the unit of book
> composition that it looks weird to me that TeX simply ignores
> that.

I think it is only a consequence of the comparatively severe memory
constraints that were prevalent in the early days of TeX's development.

> Imho, this should be handled at TeX's level rather than
> LaTeX's.

I'm not sure I understand you here. Yes, it would be good for
TeX to provide more access to certain parts of the page makeup
process; but I still think you're going to want to write custom
output routines at the macro package level. Frank Mittelbach's
multicol package effectively solves the two-page spread problem if you
adapt it for output routine use ... except that floating figures and
footnotes are still very difficult to integrate with the basic layout
strategy.

ATOM RSS1 RSS2