Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Nov 2007 22:53:41 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lAQLrZak009445 for ; Mon, 26 Nov 2007 22:53:36 +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 lAQLmA8b009665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2007 22:48:10 +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 lAQIrjgj013444; Mon, 26 Nov 2007 22:47:56 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 203030 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 26 Nov 2007 22:47:56 +0100 Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id lAQLluD8011832 for ; Mon, 26 Nov 2007 22:47:56 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id lAQLlo22009109 for ; Mon, 26 Nov 2007 22:47:54 +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-1Iwlny3uu5-0004eH; Mon, 26 Nov 2007 22:47:51 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 5B407615D5; Mon, 26 Nov 2007 22:47:50 +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> <18250.53690.194331.660833@morse.mittelbach-online.de> <005401c8305d$cf23a290$14b2a8c0@DOMINUS> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1/+ZIVj1PItzTBcYrlLQiyNijlgZpIuRrkpMUY XmY583M5bbWWET9QCvC6RGwX9J8KU3/uWSUWxO+Hv3EC5/pK1r e/Fy/PNUg5kcia3+XZTjVkafgAOZXF+ X-Spam-Whitelist-Provider: Message-ID: <18251.16134.90835.686471@morse.mittelbach-online.de> Date: Mon, 26 Nov 2007 22:47:50 +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: <005401c8305d$cf23a290$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 21:53:41.0587 (UTC) FILETIME=[CEEB7230:01C83076] Status: R X-Status: X-Keywords: X-UID: 5081 Hi Ulrich, > o.k., just some book designer's thoughts > > > 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 > > but this is already a very special case! Here I would propose to put the > vertical float area in a visual pleasing place, like the golden ratio. true, a special case but only meant as an example. but sticking with it for a moment: golden ratio between what? (i know it is also only meant as an example, but what are the ingredients?) > No, not on a per page basis. More a spec for defining float areas, top > and bottom are self-explaining but some absolute measure allows for > visually pleasing placement of 'middle' areas (and combined with a > 'vsize' option you can get a consistent layout), e.g., ok, but can you be a bit more specific as to what the pictures are supposed to tell? I'm not at all sure why there is sometimes empty space after or before the float rule (which perhaps is just meant to indicate the area for placing floats (?)= and sometimes not) so can you perhaps give some explicit pseudo specification? \DeclareFloatArea { position = m % (or t or b) ,column = 1 % 2 3 4 ... ,span = 1 % 2 3 ... ... % your spec } precise enough to make your picture example page come to life :-) ========================================= > > 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? > float area, position, size, those are clear (and i think covered) > , i think ordering is covered too (current algorithm tries areas in order specified which allos arbitrary starting order and adding a float to a certain area can close up others for further floats, ie right now each area has the additional keys class-close-list: areas that are closed if current area receives float of a certain type all-close-list: areas that are closed for all floats when current area receives a float max-float-num: maximum number of floats allowed in current area > , , aren't those more kind of decorations on the area? so in other words irrelevant for placement (other than the decorative elements might need space) or do i miss something. can you explain what you mean by "including transparency"? > spans, covered > spreads (two page spans), one day :-) > 'margin offset' (ill. goes inside margin) yes, not covered but will however, none of the above would be enough to produce a layout through an algorithm as the most important part is still missing: how (ie by what rules) is the position of the area (or some corner of it if its size is allowed to be flexible) specified? anything other than my first four options (from the original mail) or only some of them ? * 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 positioning of the floats drastically varies from page to page.) * 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. * 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 page, again with some further restrictions to the size of t1 this time. * 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 * ...other ideas... thanks frank