Received: by nummer-3.proteosys id <01C19443.3B0DB11C@nummer-3.proteosys>; Thu, 3 Jan 2002 11:41:41 +0100 Return-Path: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.3B0DB11C" x-vm-v5-data: ([nil nil nil nil nil nil t t nil][nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil nil]) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: Re: Wide things Date: Wed, 2 Jan 1991 13:00:39 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "LaTeX-L Mailing list" Sender: "Don Hosek" To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 267 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.3B0DB11C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >My first reservation is that, in publishing practice, it seems normal >[1, p. 336; 2, p. 158] to set tables in a smaller typeface than the = body of >the text. [1] says "tables may be set in small type or footnote size, = or the >size may vary from one table to another ... ". [2] seems to imply that = it >is normal to set tables in an 8-point typeface, presumably when the >body of a document is in 10-point (and suggests going down to 7- or = 6-point >if a table won't fit in 8-point). In fact [1] and [2] recognise that >"getting tables to fit" is often difficult, and devote several = paragraphs >to tactics for dealing with the difficulties. So I think that: >* the user should still get a warning if a centred thing is allowed to > spill into the margin. The user should then e.g. go and read [1] = and [2] > to decide whether to accept the "spillage" or to e.g. see whether > column-headings could be made more concise and/or decide whether to = change > font-size >* there is a case for making the font-size in the "successor to = tabular" > a feature of the design. Typically if a design has main text in = 10-point, > the design might give 8-point as the default in the "successor to = tabular". > Then (a) LaTeX would conform to what appears to me to be publishing > practice (b) the proportion of tables whose width causes problems = would > be reduced (and less users would bother people like me about them). Below is an excerpt from my LaTeX class notes which explains how I teach users to deal with the situation here and now. Although the text deals simply with centering and the like, the approach can be applied to other items of table formatting as well (many of my LaTeX styles provide a somewhat fancier aroundtbl environment built-in). The tabular environment is normally treated as just a big letter. For example, it's possible to get LaTeX to typeset something that 4 1 ii looks like 123 345 fgh in the middle of a paragraph. This is 7 12 q seldom actually desired, but useful to know. Where this becomes particularly noticable is that a tabular environment in its own paragraph is typeset with paragraph indentation, viz: 4 1 ii 123 345 fgh 7 12 q rather than flush left as you might prefer. The best way to deal with this problem is to define an aroundtbl environment which will tell LaTeX how to postion the tabular. The reason for defining an environment in this fashion is that it makes it easier to change how the tabulars will be placed: if one simply told LaTeX to center each tabular and then decided to typeset all tabulars flushleft, every instance of tabular would need to be changed. Defining the aroundtbl environment would reduce the work to simply changing a single definition. Using the aroundtbl environment, one would simply type something along the lines of the following for each tabular: \begin{aroundtbl} \begin{tabular}{cc} These columns & are \\ lined up & and centered \end{tabular} \end{aroundtbl} The following definitions are three possibilities for definining the aroundtbl environment: \newenvironment{aroundtbl}{\begin{center}}{\end{center}} will center each tabular. \newenvironment{aroundtbl}{\begin{flushright}}{\end{flushright}} will place each tabular flush against the right margin. \newenvironment{aroundtbl}{\begin{flushleft}}{\end{flushleft}} will place each tabular flush against the left margin. n.b. You should never use the center, flushright, or flushleft environments outside of the definition of a new command or environment. ------_=_NextPart_001_01C19443.3B0DB11C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Wide things

>My first reservation is that, in publishing = practice, it seems normal
>[1, p. 336; 2, p. 158] to set tables in a smaller = typeface than the body of
>the text.  [1] says "tables may be set = in small type or footnote size, or the
>size may vary from one table to another ... = ".  [2] seems to imply that it
>is normal to set tables in an 8-point typeface, = presumably when the
>body of a document is in 10-point (and suggests = going down to 7- or 6-point
>if a table won't fit in 8-point).  In fact = [1] and [2] recognise that
>"getting tables to fit" is often = difficult, and devote several paragraphs
>to tactics for dealing with the = difficulties.  So I think that:
>*  the user should still get a warning if a = centred thing is allowed to
>   spill into the margin.  The = user should then e.g. go and read [1] and [2]
>   to decide whether to accept the = "spillage" or to e.g. see whether
>   column-headings could be made more = concise and/or decide whether to change
>   font-size
>*  there is a case for making the font-size = in the "successor to tabular"
>   a feature of the design.  = Typically if a design has main text in 10-point,
>   the design might give 8-point as the = default in the "successor to tabular".
>   Then (a) LaTeX would conform to what = appears to me to be publishing
>   practice (b) the proportion of = tables whose width causes problems would
>   be reduced (and less users would = bother people like me about them).

Below is an excerpt from my LaTeX class notes which = explains how
I teach users to deal with the situation here and = now. Although the
text deals simply with centering and the like, the = approach can be
applied to other items of table formatting as well = (many of my LaTeX
styles provide a somewhat fancier aroundtbl = environment built-in).

The tabular environment is normally treated as just a = big letter.
For example, it's possible to get LaTeX to typeset = something that
          &nbs= p; 4  1    ii
looks like 123 345 fgh in the middle of a paragraph. = This is
          &nbs= p; 7  12    q
seldom actually desired, but useful to know. Where = this becomes
particularly noticable is that a tabular environment = in its own
paragraph is typeset with paragraph indentation, = viz:

    4  1    = ii
   123 345 fgh
    7  12    = q

rather than flush left as you might prefer. The best = way to deal
with this problem is to define an aroundtbl = environment which
will tell LaTeX how to postion the tabular. The = reason for
defining an environment in this fashion is that it = makes it
easier to change how the tabulars will be placed: if = one simply
told LaTeX to center each tabular and then decided to = typeset all
tabulars flushleft, every instance of tabular would = need to be
changed. Defining the aroundtbl environment would = reduce the work
to simply changing a single definition.

Using the aroundtbl environment, one would simply type = something
along the lines of the following for each = tabular:

\begin{aroundtbl}
\begin{tabular}{cc}
These columns & are \\
lined up      & and = centered
\end{tabular}
\end{aroundtbl}


The following definitions are three possibilities for = definining
the aroundtbl environment:

\newenvironment{aroundtbl}{\begin{center}}{\end{center}}

will center each tabular.

\newenvironment{aroundtbl}{\begin{flushright}}{\end{flushright}}=

will place each tabular flush against the right = margin.

\newenvironment{aroundtbl}{\begin{flushleft}}{\end{flushleft}}

will place each tabular flush against the left = margin.

n.b. You should never use the center, flushright, or = flushleft
environments outside of the definition of a new = command or
environment.




------_=_NextPart_001_01C19443.3B0DB11C--