Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 11:38:44 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lAQAcd7Y016544 for ; Mon, 26 Nov 2007 11:38:39 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lAQAUUno031474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 11:30:30 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lAPN190H013444; Mon, 26 Nov 2007 11:31:53 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 198242 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 26 Nov 2007 11:31:53 +0100 Received: from relay2.uni-heidelberg.de (relay2.uni-heidelberg.de [129.206.210.211]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lAQAVrHf001877 for ; Mon, 26 Nov 2007 11:31:53 +0100 Received: from lnx130.hrz.tu-darmstadt.de (lnx130.hrz.tu-darmstadt.de [130.83.174.24]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lAQATvJd030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Nov 2007 11:30:02 +0100 Received: from fb04281.mathematik.tu-darmstadt.de (fb04281.mathematik.tu-darmstadt.de [130.83.2.21]) by lnx130.hrz.tu-darmstadt.de (8.13.4/8.12.10) with ESMTP id lAQAVURn020170 for ; Mon, 26 Nov 2007 11:31:30 +0100 Received: from fb04197.mathematik.tu-darmstadt.de (fb04197.mathematik.tu-darmstadt.de [130.83.2.197]) by fb04281.mathematik.tu-darmstadt.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id lAQAVUkT017776 for ; Mon, 26 Nov 2007 11:31:30 +0100 Received: from fb04197.mathematik.tu-darmstadt.de (localhost [127.0.0.1]) by fb04197.mathematik.tu-darmstadt.de (8.12.3/8.12.3/Debian-7.2) with ESMTP id lAQAVTNf006210 for ; Mon, 26 Nov 2007 11:31:29 +0100 Received: (from blumensath@localhost) by fb04197.mathematik.tu-darmstadt.de (8.12.3/8.12.3/Debian-7.2) id lAQAVTvx006207 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 26 Nov 2007 11:31:29 +0100 References: <18249.57441.391405.468407@morse.mittelbach-online.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.3.28i X-TUD-HRZ-MailScanner: Found to be clean X-TUD-HRZ-MailScanner-SpamCheck: X-MailScanner-From: blumensath@mathematik.tu-darmstadt.de Message-ID: <20071126103129.GA4383@mathematik.tu-darmstadt.de> Date: Mon, 26 Nov 2007 11:31:29 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Achim Blumensath Subject: Re: Extending the output routine to middle floats To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <18249.57441.391405.468407@morse.mittelbach-online.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -2.599 () BAYES_00 X-Scanned-By: MIMEDefang 2.57 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 26 Nov 2007 10:38:45.0042 (UTC) FILETIME=[85191120:01C83018] Status: R X-Status: X-Keywords: X-UID: 5076 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Frank Mittelbach wrote: > Tackling the first question first, here are a bunch of specs that I can t= hink > of (without judging for the moment how well they would represent anything= real > life and how well they might work out in practice). >=20 > * The ratio of t1 to t2 is fixed by the design and a float AAA can be > placed into the middle position if neither t1 nor t2 become too > small. (Downside of this kind of layout might be that the positioni= ng of > the floats drastically varies from page to page.) >=20 > * The end position of t1 is fixed (vertically) so that a middle float > always starts on the same point on a page. Further restriction then= that > t2 is not getting smaller as a certain value. >=20 > * The starting starting position of t2 is fixed so that the bottom of= the > middle floats always appear on the same vertical position on the pa= ge, > again with some further restrictions to the size of t1 this time. >=20 > * An obvious extension to the above could be that there are a list of > vertical starting points to choose from and some mechanism/logic to > select one of them >=20 > * ...other ideas... Personally, I would find it awkward if the position of floats would not be consistent between pages. This would rule out options (1) and, possibly (4). What I implemented in ant is a combination of (2) and (3): The user can define a fixed area on the page where floats can be placed. In addition he specifies whether this float area should be filled up from top to bottom or from bottom to top. Achim --=20 ________________________________________________________________________ | \_____/ | Achim Blumensath \O/ \___/\ | TU Darmstadt =3Do=3D \ /\ = \| www.mathematik.tu-darmstadt.de/~blumensath /"\ o----| ____________________________________________________________________\___| --ReaqsoxgOBHFXBhH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAkdKoIEACgkQEJmibKiR73LcNwCfTtO/JyOIk4RQ9Wy5LXGKpCLV +toAnRW/Y1iRL4vPWJh4YuZ5eKJ4o+po =dLcG -----END PGP SIGNATURE----- --ReaqsoxgOBHFXBhH--