Received: from mail.proteosys.com ([213.139.130.197]) by nummer-3.proteosys with Microsoft SMTPSVC(6.0.3790.3959); Tue, 12 Feb 2008 10:39:02 +0100 Received: by mail.proteosys.com (8.13.8/8.13.8) with ESMTP id m1C9cxcT004862 for ; Tue, 12 Feb 2008 10:39:00 +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 m1C9ZG5T028552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2008 10:35:17 +0100 Received: from listserv.uni-heidelberg.de (localhost.localdomain [127.0.0.1]) by listserv.uni-heidelberg.de (8.13.1/8.13.1) with ESMTP id m1BN1EIv027429; Tue, 12 Feb 2008 10:35:07 +0100 Received: by LISTSERV.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 15.5) with spool id 208944 for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Tue, 12 Feb 2008 10:35:06 +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 m1C9Z6cv009311 for ; Tue, 12 Feb 2008 10:35:06 +0100 Received: from freebsd1.webcows.se (217198149020-host.dependit.net [217.198.149.20]) by relay2.uni-heidelberg.de (8.13.8/8.13.8) with ESMTP id m1C9Unqs008483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Feb 2008 10:30:53 +0100 Received: from [81.231.38.236] (helo=[192.168.0.179]) by freebsd1.webcows.se with esmtpa (Exim 4.64 (FreeBSD)) (envelope-from ) id 1JOaM5-0002Nd-JZ for LATEX-L@LISTSERV.UNI-HEIDELBERG.DE; Mon, 11 Feb 2008 16:14:01 +0100 Mime-Version: 1.0 (Apple Message framework v624) References: <554562.68625.qm@web82005.mail.mud.yahoo.com> <18348.49762.276704.111827@morse.mittelbach-online.de> <20ce17a8a5ca4b38f7c78f7c195108ad@residenset.net> <18351.6728.118301.982422@morse.mittelbach-online.de> <89b7a49cae0fee63aef8fbd0ca504459@residenset.net> <18352.1260.15852.715035@morse.mittelbach-online.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Mailer: Apple Mail (2.624) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - freebsd1.webcows.se X-AntiAbuse: Original Domain - listserv.uni-heidelberg.de X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - residenset.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.uni-heidelberg.de id m1C9Z6cv009312 Message-ID: <7dc63de813fac6fd90bdd54b0a891137@residenset.net> Date: Mon, 11 Feb 2008 16:13:55 +0100 Reply-To: Mailing list for the LaTeX3 project Sender: Mailing list for the LaTeX3 project From: =?ISO-8859-1?Q?Lars_Hellstr=F6m?= Subject: Re: Internal and external page setup control To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE In-Reply-To: <18352.1260.15852.715035@morse.mittelbach-online.de> Precedence: list List-Help: , List-Unsubscribe: List-Subscribe: List-Owner: List-Archive: X-ProteoSys-SPAM-Score: -2.464 () BAYES_00,FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.64 on 213.139.130.197 Return-Path: owner-latex-l@LISTSERV.UNI-HEIDELBERG.DE X-OriginalArrivalTime: 12 Feb 2008 09:39:02.0661 (UTC) FILETIME=[1A0D9B50:01C86D5B] Status: R X-Status: X-Keywords: X-UID: 5166 11 feb 2008 kl. 09.18 skrev Frank Mittelbach: > Hi Lars, > >> So what you're saying here is that all \count registers corresponding >> to float \inserts are set to 0, so that TeX's page breaking algorithm >> won't take the sizes of these floats into account when choosing a page >> break? > > yes, inserts aren't used in LaTeX (other than for keeping registers > together) > except for footnotes. floats are transparent initially and the > placement isn't > done through the insertion mechansim as already Leslie found that this > isn't > flexible enough to account even for common situations. Indeed, the LaTeX2e floats doesn't use \inserts, but use magical penalties to call the OR; fancy I didn't notice that before ... (but then ltfloat.dtx is still very Lamporty in its documentation). Was the problem that \insert requires floats to fall into disjoint classes (if [t] and [b] are separate \insert queues, then where does a [tb] float go)? Or was the problem that \inserts could not appear on the page before their position in the document? Or was it [h] floats that made \inserts insufficient? (I can't see how to do [h] with inserts, but the others seem managable if [h] is dropped, so I suppose that was the thing.) >> Hmm... And it's not possible to have TeX run the linear algorithm for >> each column separately, Using the TeX page builder ("linear algorithm") it pretty much pointless if the floats aren't \inserts that the page builder can take into account anyway, so the issue is probably moot. >> because upon encountering a multicolumn float >> in column 3 you'd have to go back and rebreak columns 1 and 2, which >> might not be possible anymore. Or is it? > > you can't go linearly unless you disallow a lot of useful and common > situations,e.g., > > - restricting floats to be only visible from the call out not that it > has to > be placed strictly after the call-out (e.g., call-out in col 2 > float placed > in column one or even on the previous page if still visible) > > - spanning columns may go backward, e.g., in a two column layout you > may want > to have a spanning 2-column float still allowed on top even if the > callout is > on the second column Both of these are so to say "linear with backtrack" -- when finding a float that affects column 1, back up and start rebreaking with modified goal. My line of thought here was mostly "Is this possible without messing up the page contents?" > both examples aren't possible with Leslie's 2e algorithm while xor can > handle > them. > >> (The OR is an area I haven't >> fiddled around with much; I imagine there might be problems with >> material and/or information being irreversibly lost when one leaves >> the >> OR.) Could of course be that it's still not good enough. If I recall it correctly, there are some things TeX throws away irreversibly, but eTeX added some primitive (discards, I think) that lets you rebreak vertical material without loss... >> [directive example] >> >> This was the expected behaviour, was it not? > > well, yes, maybe. but I don't think it will work either. or rather it > only > works in the above example because we know that the directive is > reducing the > "non-text" space therefore staying within our monotonic dependencey > rule, ie > the directive says "less floats please". If it on the other hand would > say > "more floats please" it might push the directive out to the next page. Yes, categorising directives as "increasing" or "decreasing" is certainly nontrivial, but you began by asking for *principles* for setup control, did you not? Monotonicity is a principle (the implementation of which may prove nontrivial). However, one idea could be to do the full rebreak of the page, and then compute the combined height to which the columns were split; require this quantity to be a monotonous function of rebreak count. (See pseudocode below.) > Furthermore in TeX things are not that clear cut. rebreaking does > change the > vertical flow and you may get different lengths when added together as > space > vanishes into the breaks or stuff like widows etc prevent TeX from > breaking in > certain points (like the famous example of removing a word from a > paragraph to > make it one line longer). It might still be possible to have combined text height decrease but actual amount of vertical material used increase if one makes careful combinations of penalties and large negative amounts of space, but I don't think the OR can be required to handle such situations sensibly anyway. > So my feeling is that this will still introduce "impossible documents" > and > defining rules to break out of them (which may be possible) would be > really > diffcult to implement and probably equally difficult to explain. > > which is why for anything changing the space arangement (eg float > placement > vertical sizes) I'm more and more convinced that it has to affect the > "next" > page. As an algorithm, what I've suggested would be iteration_count := 0; directives[0] := empty; REPEAT i := i + 1; UNTIL directives[i] = directives[i-1] (* Main case *) OR nonmonotonous(pagetotal[1], ..., pagetotal[i]) ; IF nonmonotonous(pagetotal[1], ..., pagetotal[i]) THEN \shipout pagetry[i-1] ELSE \shipout pagetry[i] FI; (*) Or more precisely sum of subcolumn heights, when there are middle floats. Lars Hellström