Received: from webgate.proteosys.de (mail.proteosys-ag.com [62.225.9.49]) by lucy.proteosys (8.11.0/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id f08H5l708152 for ; Mon, 8 Jan 2001 18:05:47 +0100 Received: by webgate.proteosys.de (8.11.0/8.11.0) with ESMTP id f08H5w704796 . for ; Mon, 8 Jan 2001 18:06:01 +0100 Received: from mail.Uni-Mainz.DE (mailserver1.zdv.Uni-Mainz.DE [134.93.8.30]) by mailgate2.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f08H5g007514 for ; Mon, 8 Jan 2001 18:05:42 +0100 (MET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C07995.3E60E780" Received: from mailgate1.zdv.Uni-Mainz.DE (mailgate1.zdv.Uni-Mainz.DE [134.93.8.56]) by mail.Uni-Mainz.DE (8.9.3/8.9.3) with ESMTP id SAA28863 for ; Mon, 8 Jan 2001 18:05:42 +0100 (MET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from mail.listserv.gmd.de (mail.listserv.gmd.de [192.88.97.5]) by mailgate1.zdv.Uni-Mainz.DE (8.11.0/8.10.2) with ESMTP id f08H5cM26371 for ; Mon, 8 Jan 2001 18:05:38 +0100 (MET) Received: from mail.listserv.gmd.de (192.88.97.5) by mail.listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <2.119A2E3C@mail.listserv.gmd.de>; Mon, 8 Jan 2001 18:05:38 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 479128 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Mon, 8 Jan 2001 18:05:17 +0100 Received: from ix.urz.uni-heidelberg.de (mail.urz.uni-heidelberg.de [129.206.119.234]) by relay.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id SAA01650 for ; Mon, 8 Jan 2001 18:05:16 +0100 (MET) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by ix.urz.uni-heidelberg.de (8.8.8/8.8.8) with ESMTP id SAA34784 for ; Mon, 8 Jan 2001 18:05:17 +0100 Received: from abel.math.umu.se (abel.math.umu.se [130.239.20.139]) by relay.uni-heidelberg.de (8.10.2+Sun/8.10.2) with ESMTP id f08H52U07779 for ; Mon, 8 Jan 2001 18:05:09 +0100 (MET) Received: from [130.239.20.144] (mac144.math.umu.se [130.239.20.144]) by abel.math.umu.se (8.9.2/8.9.2) with ESMTP id SAA21451; Mon, 8 Jan 2001 18:03:35 +0100 (CET) In-Reply-To: <002601c076e3$ce2a3420$78e2fea9@servus> References: Return-Path: X-Sender: lars@abel.math.umu.se x-mime-autoconverted: from quoted-printable to 8bit by relay.urz.uni-heidelberg.de id SAA01651 Content-class: urn:content-classes:message Subject: Re: templates for page layout Date: Mon, 8 Jan 2001 18:04:54 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?Lars_Hellstr=F6m?= Sender: "Mailing list for the LaTeX3 project" To: "Multiple recipients of list LATEX-L" Reply-To: "Mailing list for the LaTeX3 project" Status: R X-Status: X-Keywords: X-UID: 3649 This is a multi-part message in MIME format. ------_=_NextPart_001_01C07995.3E60E780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 07.50 +0100 2001-01-05, Ulrich Dirr wrote: [snip] >I think you should keep in mind the traditional meaning of the main = galley. I wasn't aware there was one; I was using it in the sense of "LaTeX2e*'s equivalent of TeX's main vertical list". [snip] >For book design an empty running head or a footer with only the page = count >isn't part of the text corpus. But in other designs header and footers >could be regarded part of. On the other hand they are completely = (usually) >uninteresting for typesetting the main body. I know; in fact I wrote so in a mail to this list a year ago. At 09.33 +0100 2001-01-05, Achim Blumensath wrote: [snip] >That's what I meant with `upper bound'. On the other hand, it doesn't >matter much whether the text width is, say, 340pt or 345pt. Perhaps the >ideal order would be, given a maximal value for the text width and the >ratio height/width: > > text-height =3D (ratio * max-text-width) rounded to multiples of > baseline-skip > > text-width =3D text-height / ratio Perhaps so (the difference is of the order of about 1%), but does it on = the other hand matter whether the ratio is 0.618 or 0.612? I would think changes in ratio are harder to spot. (Recall that 5/8=3D0.625 isn't = uncommon as an approximation of the golden ratio.) >> >> The main unresolved problem (which probably should be handled in >>connection >> >> to the page layout) is however how the text height and main galley = height >> >> should be related (I have written about that before), but I you = would >>need >> >> support from the output routine to sort that one out. > >I think it should be optional whether page heads and foots contribute = to >the dimensions of the textblock. Yes, not all kinds of headers/footers are part of the text rectangle = (e.g. not a footer that only contains a page number). My point is that the = text rectangle should be defined by a couple of basic layout parameters---\textheight, \textwidth, \topmargin, \oddsidemargin, and \evensidemargin say---and it should be possible to have the output = routine placing headers and/or footers inside this rectangle. Thus the height = and separation of header and footer (if they are to be set inside the text rectangle) would have to be subtracted from the text rectangle height = when the \vsize (galley height) is computed. >But in all cases the typesetting of the >textblock should be done without them. I haven't suggested anything else. [snip] >> One interesting advantage of putting the page head and foot logically >> inside the text rectangle is that one can (to some extent) ensure the = main >> galley height satsifies the multiple-of-\baselineskip restriction by >> modifying the \headsep and \footsep. In most designs there is = probably a >> range of acceptable values available. > >I don't think this is a good idea since it would result in the = textblock >having different positions/sizes on each page. No, it wouldn't! I'm not suggesting that the \headsep and \footsep = should be made skips, put in the same vertical list as the contents of \box255, and that this list should be \vboxed to \textheight. I'm suggesting that the routine (template?) which computes the \vsize should be allowed to = make small pertubations of the the values of the parameters \headsep and \footsep so that the main galley fits an integer number of lines. At 14.26 +0100 2001-01-05, Thierry Bouche wrote: >=BB The reason you should determine the text width first is that the = width of a >=BB line is very important for how easy a text is to read: if the line = is too >=BB long then it is hard to find the beginning of the next line. > >but designers don't (necessarily) work that way: you usually have the >constraint of the paper format (or choose one in the first place), >then choose the text width/height and adjust type size/leading to >achieve nice text blocks. You can't say like in current standard >classes `i want that font size/leading on that paper' and get a line >length/textheight computed, because you'd adjust the leading depending >on the line length, and the line length (together with type size) >depending on the margins... One of the nice things about the template interface is that even though = all templates of a given type to some extent have to do the same thing, they can have completely different sets of parameters. I suspect some of THEM will have to conjure up a template for the standard classes which = computes everything from the paper size and font size, but for more normal typography one would want templates more like those of Achim. BTW, = thanks for pointing out that the leading (\baselineskip) is adjusted depending = on the line width; I only had a vague impression that this parameter should = be determined at some point after the line width was. >=BB For many of >=BB the common paper formats (e.g. A4) it is more often this than the >=BB \paperwidth that is the bound you need to consider. > >it is more or less impossible to achieve a nice layout on iso paper >anyway... True, but that is no reason to make a horrible layout. If you start by specifying the text height and ratio, it's much too simple to end up = with an excessive line width by accident. [snip] >=BB That's the way the current output routine does it, yes, but it is = not the >=BB way it should be done. E.g. a headings pagestyle page head is = visually part >=BB of the text rectangle > >they're not! in fact it depends: when you have a rule under the >heading, very close to the body of the text, you consider the heading >as part of the text block, but usually, you don't. If you have folios >at the bottom of the page, they're definitely out of the text block. I >think Tschishold says something about that, but maybe I remember it >wrong. Something like that was what I wrote in my Jan. 2000 posting, yes. The point is that they can be part of the text rectangle, so the page layout parameters and output routine mechanisms should be constructed so that = they allow this. >=BB Another thing which should be included in >=BB \textheight is the (expected) depth of the page box; I doubt anyone = would >=BB want to claim that the descenders on the last line of a page are = outside > >I would. I mean that what designers choose (often with a cryptic >combination of oblique lines) is the rectangle that will apear grey in >a typical page: its top is a x-height (or cap-height) over the first >base-line, its bottom is the last baseline. In TeX, topskips >have to be quite large when you use accented caps e.g., but the real >visual text blocks starts somewhat lower. OK, I'll rephrase that: I doubt anyone would want to claim that the descenders on the last line of a page are less part of the text = rectangle than the ascenders on the first line of a page. The point is that the LaTeX2e parameter for this is asymmetric. In LaTeX2e* perhaps there = should be some kind of 'overshoot' parameter which affects both the setting of \topskip (\approx 1ex + overshoot) and the setting of \maxdepth (\approx overshoot). Lars Hellstr=F6m ------_=_NextPart_001_01C07995.3E60E780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: templates for page layout

At 07.50 +0100 2001-01-05, Ulrich Dirr wrote:
[snip]
>I think you should keep in mind the traditional = meaning of the main galley.

I wasn't aware there was one; I was using it in the = sense of "LaTeX2e*'s
equivalent of TeX's main vertical list".

[snip]
>For book design an empty running head or a footer = with only the page count
>isn't part of the text corpus. But in other = designs header and footers
>could be regarded part of. On the other hand they = are completely (usually)
>uninteresting for typesetting the main = body.

I know; in fact I wrote so in a mail to this list a = year ago.

At 09.33 +0100 2001-01-05, Achim Blumensath = wrote:
[snip]
>That's what I meant with `upper bound'. On the = other hand, it doesn't
>matter much whether the text width is, say, 340pt = or 345pt. Perhaps the
>ideal order would be, given a maximal value for = the text width and the
>ratio height/width:
>
>  text-height =3D (ratio * max-text-width) = rounded to multiples of
>          =       baseline-skip
>
>  text-width =3D text-height / ratio

Perhaps so (the difference is of the order of about = 1%), but does it on the
other hand matter whether the ratio is 0.618 or = 0.612? I would think
changes in ratio are harder to spot. (Recall that = 5/8=3D0.625 isn't uncommon
as an approximation of the golden ratio.)

>> >> The main unresolved problem (which = probably should be handled in
>>connection
>> >> to the page layout) is however how = the text height and main galley height
>> >> should be related (I have written = about that before), but I you would
>>need
>> >> support from the output routine to = sort that one out.
>
>I think it should be optional whether page heads = and foots contribute to
>the dimensions of the textblock.

Yes, not all kinds of headers/footers are part of the = text rectangle (e.g.
not a footer that only contains a page number). My = point is that the text
rectangle should be defined by a couple of basic = layout
parameters---\textheight, \textwidth, \topmargin, = \oddsidemargin, and
\evensidemargin say---and it should be possible to = have the output routine
placing headers and/or footers inside this rectangle. = Thus the height and
separation of header and footer (if they are to be = set inside the text
rectangle) would have to be subtracted from the text = rectangle height when
the \vsize (galley height) is computed.

>But in all cases the typesetting of the
>textblock should be done without them.

I haven't suggested anything else.

[snip]
>> One interesting advantage of putting the = page head and foot logically
>> inside the text rectangle is that one can = (to some extent) ensure the main
>> galley height satsifies the = multiple-of-\baselineskip restriction by
>> modifying the \headsep and \footsep. In most = designs there is probably a
>> range of acceptable values available.
>
>I don't think this is a good idea since it would = result in the textblock
>having different positions/sizes on each = page.

No, it wouldn't! I'm not suggesting that the \headsep = and \footsep should
be made skips, put in the same vertical list as the = contents of \box255,
and that this list should be \vboxed to \textheight. = I'm suggesting that
the routine (template?) which computes the \vsize = should be allowed to make
small pertubations of the the values of the = parameters \headsep and
\footsep so that the main galley fits an integer = number of lines.

At 14.26 +0100 2001-01-05, Thierry Bouche = wrote:
>=BB The reason you should determine the text = width first is that the width of a
>=BB line is very important for how easy a text is = to read: if the line is too
>=BB long then it is hard to find the beginning of = the next line.
>
>but designers don't (necessarily) work that way: = you usually have the
>constraint of the paper format (or choose one in = the first place),
>then choose the text width/height and adjust type = size/leading to
>achieve nice text blocks. You can't say like in = current standard
>classes `i want that font size/leading on that = paper' and get a line
>length/textheight computed, because you'd adjust = the leading depending
>on the line length, and the line length (together = with type size)
>depending on the margins...

One of the nice things about the template interface is = that even though all
templates of a given type to some extent have to do = the same thing, they
can have completely different sets of parameters. I = suspect some of THEM
will have to conjure up a template for the standard = classes which computes
everything from the paper size and font size, but for = more normal
typography one would want templates more like those = of Achim. BTW, thanks
for pointing out that the leading (\baselineskip) is = adjusted depending on
the line width; I only had a vague impression that = this parameter should be
determined at some point after the line width = was.

>=BB For many of
>=BB the common paper formats (e.g. A4) it is more = often this than the
>=BB \paperwidth that is the bound you need to = consider.
>
>it is more or less impossible to achieve a nice = layout on iso paper
>anyway...

True, but that is no reason to make a horrible layout. = If you start by
specifying the text height and ratio, it's much too = simple to end up with
an excessive line width by accident.

[snip]
>=BB That's the way the current output routine = does it, yes, but it is not the
>=BB way it should be done. E.g. a headings = pagestyle page head is visually part
>=BB of the text rectangle
>
>they're not! in fact it depends: when you have a = rule under the
>heading, very close to the body of the text, you = consider the heading
>as part of the text block, but usually, you = don't. If you have folios
>at the bottom of the page, they're definitely out = of the text block. I
>think Tschishold says something about that, but = maybe I remember it
>wrong.

Something like that was what I wrote in my Jan. 2000 = posting, yes. The
point is that they can be part of the text rectangle, = so the page layout
parameters and output routine mechanisms should be = constructed so that they
allow this.

>=BB Another thing which should be included = in
>=BB \textheight is the (expected) depth of the = page box; I doubt anyone would
>=BB want to claim that the descenders on the last = line of a page are outside
>
>I would. I mean that what designers choose (often = with a cryptic
>combination of oblique lines) is the rectangle = that will apear grey in
>a typical page: its top is a x-height (or = cap-height) over the first
>base-line, its bottom is the last baseline. In = TeX, topskips
>have to be quite large when you use accented caps = e.g., but the real
>visual text blocks starts somewhat lower.

OK, I'll rephrase that: I doubt anyone would want to = claim that the
descenders on the last line of a page are less part = of the text rectangle
than the ascenders on the first line of a page. The = point is that the
LaTeX2e parameter for this is asymmetric. In LaTeX2e* = perhaps there should
be some kind of 'overshoot' parameter which affects = both the setting of
\topskip (\approx 1ex + overshoot) and the setting of = \maxdepth (\approx
overshoot).

Lars Hellstr=F6m

------_=_NextPart_001_01C07995.3E60E780--