Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Nov 2007 08:52:31 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lAR7qPoM024415 for ; Tue, 27 Nov 2007 08:52:26 +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 lAR7kmql010011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2007 08:46:49 +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 lAQN1PxM013778; Tue, 27 Nov 2007 08:46:38 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 193803 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 27 Nov 2007 08:46:38 +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 lAR7kcEr020174 for ; Tue, 27 Nov 2007 08:46:38 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id lAR7ituT024606 for ; Tue, 27 Nov 2007 08:44:59 +0100 Received: from DOMINUS (p5B0CC215.dip.t-dialin.net [91.12.194.21]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1Iwv8g0sWu-0003Fd; Tue, 27 Nov 2007 08:46:33 +0100 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> <18251.16134.90835.686471@morse.mittelbach-online.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Thread-Index: Acgwdgp4EPpbmlUtSfCnUfyK1I/KAQATa9Wg X-Provags-ID: V01U2FsdGVkX1/wEuxzOnw2qr6sLx2+YnAUN8RYTZc/3B16Zy5 GVLexL1FxGkwcuBC4WJCXQuXXoviGDQHle0EgOF83v8KoQ/yKS FkuLTYXJFK/V6F6f0QGFHr4o1VcPkdC X-Spam-Whitelist-Provider: Message-ID: <006a01c830c9$d1352560$14b2a8c0@DOMINUS> Date: Tue, 27 Nov 2007 08:47:09 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Ulrich Dirr Organization: Art & Satz Subject: Re: Extending the output routine to middle floats To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <18251.16134.90835.686471@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: 27 Nov 2007 07:52:31.0298 (UTC) FILETIME=[76B24220:01C830CA] Status: R X-Status: X-Keywords: X-UID: 5083 Hi Frank, > 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?) place top of float area so that the ratio to the height of the page is like the golden ratio + a ttt ttt | ttt ttt | ttt | b AAAAA ttt | AAAAA ttt | AAAAA ttt | ttt | ttt ttt | ttt ttt + c ttt ttt bc/ac = golden ratio; e.g. if the height of page has 42\baselineskip then b would start after line 16 (if I calculated correctly ;-) > > 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) the rule in the picture should have indicated the area, the empty space means that for a consistent design -- if the concrete application is suitable for that -- you reserve the same vertical amount and place the pictures top aligned with respect to the area. Of course this will only work in an application where there aren't very tall pictures ... but then a fixed middle area wouldn't be the right design. > 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 > } \DeclareFloatArea { position = m % (or t or b) ,column = 1 % 2 3 4 ... ,span = 1 % 2 3 ... ,vsize = 6\baselineskip % vsize of area ,pos = absolute(16\baselineskip) % vertical starting position } > precise enough to make your picture example page come to life :-) maybe a global definition which can be overridden is more useful, e.g., \DeclareFloatAreaMiddle { columns = all % {1-3}, {1,2} ,vsize = 6\baselineskip % vsize of area ,pos = absolute(16\baselineskip) % vertical starting position } then in case of a float like on my page 117 we define \DeclareFloatAreaSpan { ,columns = {1, 2} % applies to columns 1 and 2; other possibilities '{1-3}, all' ,span = {1, 2} % span applies to columns 1 and 2; '{1-3}, all' } > ========================================= > > > > 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 this should be covered by my above definition (text above 16\baselineskip, float area 6\baselineskip, text after 42-(16+6)\baselineskip). > > , , > > 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. yes, that's true but where do you define global definitions for the visual appearance? And one should always have the possibility to override some specs, e.g. in a special case one might not want top rules. \DeclareFloatArea \DeclareFloatArea % if necessary \DeclareFloatAreaAppearance % ? > can you explain what you mean by "including transparency"? You should be able to define background colour|pictures, rules (top, bottom, box, coloured), transparency for background colour|pictures and maybe even a gradient colour. Plus a command to override the global definition in a special case. > * 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. I thought this was what I'd proposed. > * 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... sorry if my explanations are too cryptic. Ulrich