Received: by nummer-3.proteosys id <01C19443.3B19EADC@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.3B19EADC" 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: Tables (which may be wide) Date: Wed, 9 Jan 1991 22:01:08 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "LaTeX-L Mailing list" Sender: To: "Rainer M. Schoepf" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 269 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.3B19EADC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would there be a consensus in favour of the following? 1. Have a standard name for "an environment into which people normally put non-floated tables". Names currently on offer include Don Hosek's "aroundtbl" and my "displaytable". I'll use the name "N" below (where N denotes an unknown). 2. In the manual, mention N (as the environment into which the user normally puts a table) before mentioning center, etc. (to which the = user might have to resort if user intervention is required for a = particularly awkwardly sized table). 3. In the standard styles, have a fairly simple definition of N, but one which conforms to a common publishing convention. E.g., in the successors to report, article and book, something like \newenvironment{N}{\begin{center}\begin{footnotesize}}% {\end{footnotesize}\end{center}} would do (although a definition involving Nelson's widecenter or Frank's "center with attributes" could be used). Thus the user would go \begin{N} \begin{tabular}{...} % or tabbing, or their successors ... \end{tabular} \end{N} I'd justify the footnotesize as a "common publishing convention" by reference to Butcher's book and the Chicago Manual of Style (see my = last mail) which both talk in terms of tables usually being set in a = smaller typeface than the main text (but people who work for publishers = would be better placed than me to advise). Such definitions should be sufficiently simple that they don't generate "3 bugs/month for 10 = years". Yet the existence of N would make it clear "what one should do with = a table" and having a reduction in size as standard (if adopted) would save a bit of "support" time by allowing more information in before problems of size arise. 4. If someone is writing a style-file for a particular application, and = has to implement a particular design, it will be up to them how = ambitious they are in their re-definition of N. People attenting Don Hosek's classes might simply replace center by flushright or flushleft. If a "a woman editor of a physics journal" has to enforce a = house-style that doesn't lend itself to a simple re-definition of N, it would be = up to her whether she goes for: (a) a complicated re-definition of N, in the hope that, although she = can expect to spend time finding bugs in her definition, the time = she spends on coding and bug-fixes may be less than the time she would have = spent in "visual formatting", (b) visual formatting, by replacing N by lower-level commands in the few cases when the simple definition leaves things sticking into a margin (or margins). If she goes for (a), and is sufficiently confident of the code to = put it "in the public domain", people will look to her for maintenance of = the code, not to the people who produced the simple code in the = standard styles. Similarly, it would be open for someone writing their own style = file to try making N intelligent enough to "fit" awkwardly sized tables automatically, but maintenance would be a matter for them. E.g. if someone produces a style-file that lays a document out in the style of the PostScript manuals, it would be up to them whether they try to make N intelligent enough to use the "heading margin" when = "necessary", and if so whether they risk putting the style-file in the public = domain. Nothing they did would imply any additional maintenance for the simple definitions used in the "standard styles". There would then be the following open questions: * the name to be used for N * the relationship with the "floating environments". Should it be possible to have a common numbering sequence for the = captions for both fixed and floating tables? If so, it would presumably be = necessary to define N so that, as far as floats were concerned, it was as if a \begin{table}[h] had been possible. Otherwise, numbering could get = out of sequence if a floated-table floated past a fixed-table. Should a float automatically do an N? If it's an environment that's specifically designed to float tables, I'd say "yes" for the standard styles, although obviously anyone writing anything else could do what they liked. David = Rhead ------_=_NextPart_001_01C19443.3B19EADC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tables (which may be wide)

Would there be a consensus in favour of the = following?

1.  Have a standard name for "an environment = into which people normally
    put non-floated = tables".  Names currently on offer include Don
    Hosek's "aroundtbl" and = my "displaytable".  I'll use the name = "N"
    below (where N denotes an = unknown).

2.  In the manual, mention N (as the environment = into which the user
    normally puts a table) before = mentioning center, etc. (to which the user
    might have to resort if user = intervention is required for a particularly
    awkwardly sized table).

3.  In the standard styles, have a fairly simple = definition of N, but
    one which conforms to a common = publishing convention. E.g., in the
    successors to report, article and = book, something like
       = \newenvironment{N}{\begin{center}\begin{footnotesize}}%
       = {\end{footnotesize}\end{center}}
    would do (although a definition = involving Nelson's widecenter
    or Frank's "center with = attributes" could be used). Thus the user
    would go
      \begin{N}
      = \begin{tabular}{...}  %  or tabbing, or their = successors
      ...
      \end{tabular}
      \end{N}
    I'd justify the footnotesize as a = "common publishing convention" by
    reference to Butcher's book and = the Chicago Manual of Style (see my last
    mail) which both talk in terms of = tables usually being set in a smaller
    typeface than the main text (but = people who work for publishers would
    be better placed than me to = advise).  Such definitions should be
    sufficiently simple that they = don't generate "3 bugs/month for 10 years".
    Yet the existence of N would make = it clear "what one should do with a
    table" and having a reduction = in size as standard (if adopted) would
    save a bit of "support" = time by allowing more information in before
    problems of size arise.

4.  If someone is writing a style-file for a = particular application, and has
    to implement a particular design, = it will be up to them how ambitious
    they are in their re-definition of = N.

    People attenting Don Hosek's = classes might simply replace center by
    flushright or flushleft.

    If a "a woman editor of a = physics journal" has to enforce a house-style
    that doesn't lend itself to a = simple re-definition of N, it would be up
    to her whether she goes = for:
    (a) a complicated re-definition of = N, in the hope that, although she can
        expect to = spend time finding bugs in her definition, the time she spends
        on coding = and bug-fixes may be less than the time she would have spent
        in = "visual formatting",
    (b) visual formatting, by = replacing N by lower-level commands in the
        few cases = when the simple definition leaves things sticking into
        a margin = (or margins).
     If she goes for (a), and is = sufficiently confident of the code to put it
     "in the public = domain", people will look to her for maintenance of the
     code, not to the people who = produced the simple code in the standard
     styles.

     Similarly, it would be open = for someone writing their own style file
     to try making N intelligent = enough to "fit" awkwardly sized tables
     automatically, but = maintenance would be a matter for them.  E.g. if
     someone produces a = style-file that lays a document out in the style
     of the PostScript manuals, = it would be up to them whether they try
     to make N intelligent enough = to use the "heading margin" when "necessary",
     and if so whether they risk = putting the style-file in the public domain.
     Nothing they did would imply = any additional maintenance for the
     simple definitions used in = the "standard styles".


There would then be the following open = questions:

*  the name to be used for N

*  the relationship with the "floating = environments".

   Should it be possible to have a common = numbering sequence for the captions
   for both fixed and floating = tables?  If so, it would presumably be necessary
   to define N so that, as far as floats = were concerned, it was as if a
   \begin{table}[h] had been = possible.  Otherwise, numbering could get out of
   sequence if a floated-table floated past = a fixed-table.

   Should a float automatically do an = N?  If it's an environment that's
   specifically designed to float tables, = I'd say "yes" for the standard
   styles, although obviously anyone = writing anything else could do what
   they liked.

          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;      David Rhead


------_=_NextPart_001_01C19443.3B19EADC--