Received: by nummer-3.proteosys id <01C19443.9FAE8794@nummer-3.proteosys>; Thu, 3 Jan 2002 11:44:30 +0100 Return-Path: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19443.9FAE8794" x-vm-v5-data: ([nil nil nil nil nil nil nil nil 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: {1} Size options (and alternatives) Date: Sun, 8 Mar 1992 18:46:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: Sender: "LaTeX-L Mailing list" To: "Multiple recipients of" Reply-To: "LaTeX-L Mailing list" Status: R X-Status: X-Keywords: X-UID: 615 This is a multi-part message in MIME format. ------_=_NextPart_001_01C19443.9FAE8794 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a comment about Phil's comment (about my comment about Rocky Bernstein's request). Is generic style-file that, when it's been given a certain minimum number of dimensions (and perhaps other parameters), yields a good = design attainable? At best, it would require a lot of thought and testing: how = to get "good design" for all permutations of things that the user might change; all combinations of variables would need trying and the = resulting designs assessing. At worst, we'd have people around the world = muttering "I don't like the LaTeX 3.0 standard styles" just like they go round muttering "I don't like the LaTeX 2.09 standard styles" now. And do we want a lot of "authors" specifying parameters for "document design", or would we prefer to have a division of labour between "the author" and = "the document designer"? Would something like the following be preferable (where by BK-L, ART-L, SER-L, I mean "whatever structure LaTeX supports that is analogous to = the AAP's BK-1, ART-1, SER-1" or, alternatively, the 2.09 book, article, = etc. STRUCTURES as distinct from the 2.09 book, article, etc. DESIGNS)? A 3-category hierarchy of style-files, with varying methods/degrees of support: Category 1. For each structure, ONE DESIGN ONLY. Although one would aim to make the designs easy to read (11pt font = for main text, standard typesetting inter-line spacing, not too many characters/line), the only claims made would be: - they give a mapping of the structures onto paper or, to be more specific, ... - they map the structures onto standard laserprinter paper (i.e., A4 or the US equivalent), hence ... - they give one way of checking DRAFT documents - they will be available at all sites that have LaTeX 3.0, hence = ... - they are suitable for "getting something to read" when LaTeX = input files are sent by e-mail - they are NOT intended for typesetting documents ready for = publication - they do NOT claim to be suitable for use, unchanged, for in-house documents such as technical reports, theses, etc. - they do NOT have the intelligence to give good design for various point/paper sizes. Produced and supported by "the project team". The command to get = one of these would NOT imply that the resulting output could be used = for "camera ready copy" or for "publication as-is" in any other way. E.g., \mapping{BK-L}{draft} might be OK, but \documentstyle{book} wouldn't (since the latter suggests you'll get a book ready to send off to a publisher, which you won't). Category 2. High-quality REPRESENTATIVE EXAMPLES of style-files that = are intended for typesetting documents for publication or are intended = for producing specific in-house documents. For each "supported structure", a couple of style-files that show how to produce REAL-WORLD documents, such as style-files that typeset: - the BK-L structure in an AMS monograph design (for printing on whatever paper the AMS actually uses). Alternatively (if fonts = are a problem) a similar style-file that uses CMR, and/or a \mapping{BK-L}{AMSmonograph}[draft] design. - the BK-L structure in a RHBNC thesis design (for printing on A4, = if that's what RHBNC uses for theses) - the BK-L structure in a DEC technical report design (for printing = on whatever paper DEC uses for its technical reports) - the ART-L structure in an Elsevier journal design. - the ART-L structure in some real publisher's "paper in conference-proceedings" design - the SER-L structure in a Springer journal design (showing how a = SER-L can be made up of papers drafted as ART-L) - the SER-L structure in an AMS conference-proceedings design (again made up of things drafted as ART-L). To be representative, the real-world examples would have to include style-files that give: twocolumn design, PostScript fonts, = "constant line-spacing not glue" design, ragged-right design. Produced in liaison with "the project team", and used for testing LaTeX 3.0 (since LaTeX 3.0's features for typesetting real-world documents will need testing somehow). The target paper-size would = be documented/crop-marked in each case. A publisher whose style-files are in this category would have to agree to allow the style-files = to be in the public-domain (in the standard LaTeX 3.0 distribution, = even). In return, the publisher would get more support than other = publishers get (and hackers would get a representative sample of well-written style-files to start hacking at). There would have to be some convention about who is in charge of each of these (e.g., "the publisher, but the project team retains the right to stop liaising and/or stop distribution if the publisher doesn't maintain the style-file at the quality expected"). The project team might influence things so that the software is modular. We may still have people going round saying "I don't like = design", but: - the chances are that real publishers will have reasonable designs - it will be clear that the design is "the publisher's fault", not "LaTeX's fault" - it will be clear that the style-files are only examples: no-one = but has to use a design if they don't like it. Category 3. No support from "the project team". Style-files that other publishers/hackers produce. These would generally be based on the examples given in category 2. (Since category 2 gives "real world" designs, category 3 will tend to inherit "good designs". Category = 3 will NOT be based on category 1, because it would be made clear = that category 1 styles aren't intended to give "camera-ready copy" or anything else that is suitable for final publication.) Used "in = house" by publishers or supplied privately to "their authors". Placed in archives by hackers. Variable quality (so publishers/hackers would = be advised to start hacking at the category 2 files rather than at these). Such an approach might give "the project team" a finite task [just one design for each structure for category 1] as opposed to the task of = trying to make generic files intelligent to all end-user's ideas of font/paper = size [and probably still having people muttering that they "don't like the = LaTeX output" at the end of the attempt]. Design responsibilities would generally get devolved away from "the project team" to publishers, which would be one less thing for "the project team" to worry about [although = in practice, the people doing category 2 style-files might sometimes be = "project team" people in a different (but paid?) role]. It might even achieve Phil's objectives (design that is appropriate for = the paper-size and vice-versa) by doing the opposite of what he suggests! I.e., instead of worrying about what generic designs should do, don't attempt generic designs --- then they won't have any default dimensions associated with them. If we are already on good terms with "Runnymede books", they could be invited to liaise about production of a "category 2" style-file that = could give the world a good example of "how to do a quarto edition with = LaTeX". If not, Runneymede books might eventually take a category 2 style-file = that WAS produced in liaison with a professional publisher, and hack at it = until it gives a (category 3) style-file that does what their book-designer wants. David Rhead JANET: d.rhead@uk.ac.nottingham.ccc.vme ------_=_NextPart_001_01C19443.9FAE8794 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable {1} Size options (and alternatives)

This is a comment about Phil's comment (about my = comment about Rocky
Bernstein's request).

Is
   generic style-file that, when it's been = given a certain minimum
   number of dimensions (and perhaps other = parameters), yields a good design
attainable?  At best, it would require a lot of = thought and testing: how to
get "good design" for all permutations of = things that the user might
change; all combinations of variables would need = trying and the resulting
designs assessing.  At worst, we'd have people = around the world muttering
"I don't like the LaTeX 3.0 standard = styles" just like they go round
muttering "I don't like the LaTeX 2.09 standard = styles" now.  And do we
want a lot of "authors" specifying = parameters for "document design", or
would we prefer to have a division of labour between = "the author" and "the
document designer"?

Would something like the following be preferable = (where by BK-L, ART-L,
SER-L, I mean "whatever structure LaTeX supports = that is analogous to the
AAP's BK-1, ART-1, SER-1" or, alternatively, the = 2.09 book, article, etc.
STRUCTURES as distinct from the 2.09 book, article, = etc. DESIGNS)?

A 3-category hierarchy of style-files, with varying = methods/degrees of
support:

Category 1.  For each structure, ONE DESIGN = ONLY.
     Although one would aim to = make the designs easy to read (11pt font for
     main text, standard = typesetting inter-line spacing, not too many
     characters/line), the only = claims made would be:
     - they give a mapping of the = structures onto paper or, to be more
       specific, = ...
     - they map the structures = onto standard laserprinter paper (i.e.,
       A4 or the US = equivalent), hence ...
     - they give one way of = checking DRAFT documents
     - they will be available at = all sites that have LaTeX 3.0, hence ...
     - they are suitable for = "getting something to read" when LaTeX input
       files are sent = by e-mail
     - they are NOT intended for = typesetting documents ready for publication
     - they do NOT claim to be = suitable for use, unchanged, for
       in-house = documents such as technical reports, theses, etc.
     - they do NOT have the = intelligence to give good design for
       various = point/paper sizes.
     Produced and supported by = "the project team".  The command to get one
     of these would NOT imply = that the resulting output could be used for
     "camera ready = copy" or for "publication as-is" in any other way.
     E.g., \mapping{BK-L}{draft} = might be OK, but \documentstyle{book}
     wouldn't (since the latter = suggests you'll get a book ready to send
     off to a publisher, which = you won't).

Category 2.  High-quality REPRESENTATIVE EXAMPLES = of style-files that are
     intended for typesetting = documents for publication or are intended for
     producing specific in-house = documents.  For each "supported
     structure", a couple of = style-files that show how to produce
     REAL-WORLD documents, such = as style-files that typeset:
     - the BK-L structure in an = AMS monograph design (for printing on
       whatever paper = the AMS actually uses).  Alternatively (if fonts are a
       problem) a = similar style-file that uses CMR, and/or a
       = \mapping{BK-L}{AMSmonograph}[draft] design.
     - the BK-L structure in a = RHBNC thesis design (for printing on A4, if
       that's what = RHBNC uses for theses)
     - the BK-L structure in a = DEC technical report design (for printing on
       whatever paper = DEC uses for its technical reports)
     - the ART-L structure in an = Elsevier journal design.
     - the ART-L structure in = some real publisher's "paper in
       = conference-proceedings" design
     - the SER-L structure in a = Springer journal design (showing how a SER-L
       can be made up = of papers drafted as ART-L)
     - the SER-L structure in an = AMS conference-proceedings design
       (again made up = of things drafted as ART-L).
     To be representative, the = real-world examples would have to include
     style-files that give: = twocolumn design, PostScript fonts, "constant
     line-spacing not glue" = design, ragged-right design.

     Produced in liaison with = "the project team", and used for testing
     LaTeX 3.0 (since LaTeX 3.0's = features for typesetting real-world
     documents will need testing = somehow).  The target paper-size would be
     documented/crop-marked in = each case.  A publisher whose style-files
     are in this category would = have to agree to allow the style-files to be
     in the public-domain (in the = standard LaTeX 3.0 distribution, even).
     In return, the publisher = would get more support than other publishers
     get (and hackers would get a = representative sample of well-written
     style-files to start hacking = at).  There would have to be some
     convention about who is in = charge of each of these (e.g., "the
     publisher, but the project = team retains the right to stop liaising
     and/or stop distribution if = the publisher doesn't maintain the
     style-file at the quality = expected").  The project team might
     influence things so that the = software is modular.

     We may still have people = going round saying "I don't like <publisher's>
     design", but:
     - the chances are that real = publishers will have reasonable designs
     - it will be clear that the = design is "the publisher's fault", not
       "LaTeX's = fault"
     - it will be clear that the = style-files are only examples: no-one but
       = <publisher> has to use a design if they don't like it.

Category 3.  No support from "the project = team".  Style-files that other
     publishers/hackers = produce.  These would generally be based on the
     examples given in category = 2.  (Since category 2 gives "real world"
     designs, category 3 will = tend to inherit "good designs".  Category 3
     will NOT be based on = category 1, because it would be made clear that
     category 1 styles aren't = intended to give "camera-ready copy" or
     anything else that is = suitable for final publication.) Used "in house"
     by publishers or supplied = privately to "their authors".  Placed in
     archives by hackers.  = Variable quality (so publishers/hackers would be
     advised to start hacking at = the category 2 files rather than at
     these).

Such an approach might give "the project = team" a finite task [just one
design for each structure for category 1] as opposed = to the task of trying to
make generic files intelligent to all end-user's = ideas of font/paper size
[and probably still having people muttering that they = "don't like the LaTeX
output" at the end of the attempt].  Design = responsibilities would
generally get devolved away from "the project = team" to publishers, which
would be one less thing for "the project = team" to worry about [although in
practice, the people doing category 2 style-files = might sometimes be "project
team" people in a different (but paid?) = role].

It might even achieve Phil's objectives (design that = is appropriate for the
paper-size and vice-versa) by doing the opposite of = what he suggests!
I.e., instead of worrying about what generic designs = should do, don't
attempt generic designs --- then they won't have any = default dimensions
associated with them.

If we are already on good terms with "Runnymede = books", they could be
invited to liaise about production of a = "category 2" style-file that could
give the world a good example of "how to do a = quarto edition with LaTeX".
If not, Runneymede books might eventually take a = category 2 style-file that
WAS produced in liaison with a professional = publisher, and hack at it until
it gives a (category 3) style-file that does what = their book-designer
wants.



David Rhead
JANET: d.rhead@uk.ac.nottingham.ccc.vme

------_=_NextPart_001_01C19443.9FAE8794--