Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 15:10:42 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lAQEAbux028164 for ; Mon, 26 Nov 2007 15:10:37 +0100 Received: from listserv.uni-heidelberg.de (listserv.uni-heidelberg.de [129.206.100.94]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id lAQE1pGi018420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 15:01:51 +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 lAPN19FX013444; Mon, 26 Nov 2007 15:01:41 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 200380 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 26 Nov 2007 15:01:41 +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 lAQE1fMf020032 for ; Mon, 26 Nov 2007 15:01:41 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lAQDxxJu027093 for ; Mon, 26 Nov 2007 15:00:03 +0100 Received: from morse.mittelbach-online.de (p54A9B85C.dip0.t-ipconnect.de [84.169.184.92]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis) id 0MKwpI-1IweWk1jsY-0004Tu; Mon, 26 Nov 2007 15:01:36 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 7F0F0615D5; Mon, 26 Nov 2007 15:01:30 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <18249.57441.391405.468407@morse.mittelbach-online.de> <008a01c83026$f01a3900$14b2a8c0@DOMINUS> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX19EcNwxEqMf28b4v5xRIGGHqy/47X5apSRvad2 kq3NY+/5gEkZ2yOGuCss5clYinI1eU7a/J0AqSY0HmU430+S9E N5KoGFkL+2LckYJ/8WdWlWhBXs0RMAu X-Spam-Whitelist-Provider: Message-ID: <18250.53690.194331.660833@morse.mittelbach-online.de> Date: Mon, 26 Nov 2007 15:01:30 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: Extending the output routine to middle floats To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <008a01c83026$f01a3900$14b2a8c0@DOMINUS> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -102.464 () BAYES_00,FORGED_RCVD_HELO,USER_IN_WHITELIST 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 14:10:42.0535 (UTC) FILETIME=[21507F70:01C83036] Status: R X-Status: X-Keywords: X-UID: 5078 Hi Ulrich, > in my opinion middle floats always float ;-) "Middle" floats could float > from the column top to the column bottom; if there's room left before or > after one should apply the standard orphan/widow rules (but if a > designer wants a fixed middle placement one should have an option like > the absolute placement for top and bottom position). They can be of > different size and therefore I don't think there is a algorithm that > will satisfy all possible combinations automatically. As said there > should be a possibility for a fixed position on the page, e.g., on top > or bottom or both (wether in single column mode or more) and maybe even > in combination with column number, e.g., left column, middle, right (or > one, two, three, ...) -- In this case I would like to have an option to > place some text at the original position when the float has been moved. I didn't meant to discuss "here" floats as in LaTeX2e which indeed nearly always float :-) ---and if they do, your idea of allowing some alternate text to appear is a good one. I was/am after a design that supports one or more float area that is not on the top/bottom of the page but somewhere within the page, i.e., a place or more where floats float into, for example in a design where part of the margin is being used for floats ttt ttt ttt ttt ttt AAAAA ttt AAAAA ttt AAAAA ttt ttt ttt ttt ttt ttt ttt ttt you are quite right that no algorithm can satisfy everything, but the question is what can be done algorithmically that satisfies at least something? > > To state the problem differently, what should be the amount of freedom > > available to the designer (through the algorithm), and what would be a > good > > way to express it? > > No restrictions! that algorithm wouldn't work and wouldn't place anything. remember this is not trying to build InDesign or Quark inside LaTeX this is about autmatically placing floats and any such algorithm needs rules of some kind. take the 2.09 algorithm, that one basically had the following rules: - place as many floats as possible (and as early as possible) that are not in conflict with any other rule - for unplaced floats try to produce float pages (sub of previous rule) - restrict placement through - number of floats per page - number of floats per float area - size of float area - remaining size of text - keep order of floats within type - require that float is placed after callout or in same column on top - honor area placement options on individual float (and have defaults per type) 2e extended that minimally by supporting overwrite on a per float basis (! syntax) and supporting strict-after-callout through flafter the xor implementation has already changed that drastically by supporting - spanning float areas across multiple columns (in a multi-column design with cols >=2), - relations betwen float areas, e.g., if a float is place in one area, other areas may not be allowed to receive floats - more flexibility in specifying float callout relation > > Questions: > > > > * What kind of other specs can you think of? > > for fixed positions: > [col=1, pos=, col=2, pos=, col=3, pos=, ...] or > even > [col=1, pos=absolute(10cm), ...], [col=1, pos=absolute(10\baselineskip), > ...], or [col=1, pos=(10\baselineskip), ...] > If I understand this correctly than those are suggestions more in line of spcifying layout on a per page basis, e.g. place this float in that position on this page ... That is a different beast altogether and in fact xor will have this ability too (though right now it is broken) But what I'm after is this: - assuming you have the possibility of specifying one (or more?) middle areas for floats by which I mean an area to receieve float(s) where above and below there is still text - when what kind of algorithmic specifications and rules should govern this area and how it is filled? thanks frank