Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Dec 2007 22:37:38 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lB6LbWbb031070 for ; Thu, 6 Dec 2007 22:37:33 +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 lB6LU9pj009419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 22:30: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 lB6FxrPt024234; Thu, 6 Dec 2007 22:31:57 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 207093 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Thu, 6 Dec 2007 22:31:57 +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 lB6LVvlh021323 for ; Thu, 6 Dec 2007 22:31:57 +0100 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by relay.uni-heidelberg.de (8.14.1/8.14.1) with ESMTP id lB6LVqm3013017 for ; Thu, 6 Dec 2007 22:31:56 +0100 Received: from morse.mittelbach-online.de (p54A9A897.dip0.t-ipconnect.de [84.169.168.151]) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis) id 0ML31I-1J0OJz1gTW-0007M6; Thu, 06 Dec 2007 22:31:51 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id E621451FBA; Thu, 6 Dec 2007 22:31:50 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <18251.18406.62310.939815@morse.mittelbach-online.de> <475826B1.6080309@arcor.de> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1/B6yXex/PehsF6LgwpRwsF6LedUKv/ue0trdE w5axso1UpYJ90D51aK53X65dtQyli1/JOTINrSFt3Xi5W36RD8 2RfSrRCGXwn0L2BhFwwXXCoqZF9DqvD X-Spam-Whitelist-Provider: Message-ID: <18264.27206.909337.443883@morse.mittelbach-online.de> Date: Thu, 6 Dec 2007 22:31: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 allow float placement styles To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <475826B1.6080309@arcor.de> 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: 06 Dec 2007 21:37:38.0378 (UTC) FILETIME=[38EEEAA0:01C83850] Status: R X-Status: X-Keywords: X-UID: 5101 Stephan > > floatpage-odd & A right-hand page with only floats \\ > > floatpage-even & A left-hand page with only floats \\ > > > > [...] > > > > details can be read at > > http://www.latex-project.org/svnroot/experimental/trunk/xpackages/xor/xo-pagestyle.dtx > > (which hopefully compiles with std LaTeX2e (plus the .sty file in the same > > dir) > > Related or not ... > > Is it possible with the new OR to restrict floats to left-hand /or/ > right-hand pages? That is, is it possible to output floats only on > left-hand pages? the simple answer is more or less. basically if your float style for right hand pages would not allow any float areas than consequentually you would have only text there and floats only on the left and/or text. but float pages could interfere in therory not directly supported by this scheme would be a design that would only allow floatpages or empty pages on one side, but if that is something worth having once could probably accommodate for that as well --- is that what you are asking? > (iii) A generalization could be to let text (and floats) flow through > an arbitrary page number pattern (useful for critical editions?) it would be interesting to come up with a spec for this. basically what would be missing for something like this is a way to control float pages. right now the algorithm doesn't control them at all, i.e. it tries to built them the moment there are enough floats and would output them anywhere. so to get to such an extension one would need to think about how to specify how float pages could be controlled. frank