Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Dec 2007 00:27:15 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id lBANRAsI019519 for ; Tue, 11 Dec 2007 00:27:10 +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 lBANNYBv009120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2007 00:23:34 +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 lBAN1AgS027990; Tue, 11 Dec 2007 00:23:20 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.0) with spool id 220349 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 11 Dec 2007 00:23:19 +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 lBANNJGd028662 for ; Tue, 11 Dec 2007 00:23:19 +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 lBANNFtD008116 for ; Tue, 11 Dec 2007 00:23:19 +0100 Received: from morse.mittelbach-online.de (p54A98902.dip0.t-ipconnect.de [84.169.137.2]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1J1rxx3v5d-0001Xj; Tue, 11 Dec 2007 00:23:14 +0100 Received: by morse.mittelbach-online.de (Postfix, from userid 501) id 1C25B61798; Tue, 11 Dec 2007 00:23:08 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <18263.4996.905115.46103@morse.mittelbach-online.de> <00a901c837d7$c291a3c0$14b2a8c0@DOMINUS> <18263.44547.318795.848131@morse.mittelbach-online.de> <006201c83813$ad508ad0$14b2a8c0@DOMINUS> <18265.12916.555104.35087@morse.mittelbach-online.de> <20071210173045.GA23382@edgard.fdn.fr> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Provags-ID: V01U2FsdGVkX1+k/SYaqsdmcKDK+SS2c7aFtepPFcdyO5F+Asz m72EeL/R9H2yvtGa1l8ow7+pKsyYjtl1sVXKpExa7W92JtTf9u 6LkW+qjbyXVLyHzLmKiTSLhAE2ItWHt X-Spam-Whitelist-Provider: Message-ID: <18269.51803.637796.115560@morse.mittelbach-online.de> Date: Tue, 11 Dec 2007 00:23:07 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: Frank Mittelbach Subject: Re: progress ... balancing, grids, multicolumn changes ... To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <20071210173045.GA23382@edgard.fdn.fr> 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: 10 Dec 2007 23:27:15.0468 (UTC) FILETIME=[32D634C0:01C83B84] Status: R X-Status: X-Keywords: X-UID: 5115 Hi Benjamin, > Le Fri, Dec 07, 2007 at 12:45:56PM +0100, Frank Mittelbach: > > > > layout is called "ftnrightspread" and you can review the results in the pdf > > I see one interesting case, about footnotes and multicolumn. The usual > layout is to have N cols, with the footnotes of each columns at the > bottom of it. It might be interesting to have a layout with different > numbers of cols for the text and the notes. > > Something like a 2 columns text with a 3 columns footnote area, when there > is a quite large difference in text size between text and notes, it > avoid having too long lines in the notes. that is certainly an interesting but probably non-trivial variation/extension in fact, even balancing the footnotes (without changing the column width would be an extension of what is there, but posing the same problems really). Technically one problem is to actually sync the space occupied by the footnotes with the generation of columns (though there are some possibilities to get that right more or less all the time -- if i remember correctly the TeX book even has some code in appendix D for that) but then there is also a certain difficulty how to handle the case that a page doesn't contain many footnotes. what should be done in this case? running 3 one-liners across the page may look horrible for example. and if one changes behavior in that case then the space calculation may become difficult if not impossible. anyway, anybody any ideas how this conceptually should behave? > I don't know how to have that kind of thing integrated as a parameter in > a more global layout. that would be the least of my worries :-) > Another case interesting in mixing various numbers of columns, and that > can be handled, is having a "break" across all columns, but not only at > the top of the page, like a "middle title". I don't know how it fits > with the float placement system, it would be a kind of gluing together a > page with balanced columns and no bot floats (the top part) and a page > with a cross-cols title (the bottom part). I'm thinking about this problem for a long long time and haven't found a suitable or say satisfying algorithmic approach to it. what is probably doable without too much complication is to allow titles to go across the page, ie to balance run a title in single column mode and then return back to the same number of columns as before. the above idea to force earlier floats into the top part could then be simply handled with flush points (well perhaps somewhat extended) what i never got any good idea on how to handle it with the complication of floats is to change the column numbers for good, e.g. 3-columns then balance then continue with two columns or something along those lines. the problem with the current algorithm is that it builds up float by float so changing column numbers will change the width of the float areas which poses one problem. another problem then would be the area setup for a page would then largly depend on the content of the page while right now it is static (which helps) at least static in the sense that one knows what one is aiming for for a particular page. and then there is of course the problem what you do if you have 2 such balance points on a page and a float that sits in the second block. what is that going to go to? i'm not saying nothing can be done, just that this really is difficult to be addressed by some algorithmic approach in a suitable manner and much more easily done with a totally visual tool. I mean, the current 2e algorithm is fairly trivial in the amount of possibilities and alternatives and still many people are baffled by the decisions the algorithm takes sometimes. Now, part of that is probably due to the fact that it doesn't offer a way to show why it made certain decisions --- one of the reasons why the xor comes with plenty of info (not the tracing one but the one you get when you compile with "progress" option) but to some extend it is simply due to the fact that a statement like "down here this particular figure would fit nicely" doesn't easily translate in an algorithm that has to base its decision on abstract stuff like "bottom figures no larger than X, no top right figure if there is a top left one ..." > Since a multi column is more suited for large page sizes, it can be > interesting to have such "middle" titles. yes. which is why i'm experimenting with the balancing in connection with floats but ... :-) good night frank