LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Lars Hellström <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Mon, 11 Feb 2008 16:13:55 +0100
text/plain (151 lines)
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 (<something>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 

> 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;
    i := i + 1;
    <break page (under settings current at page start modified by
     directives[i-1]), save as pagetry[i], record sum of column(*) 
     as pagetotal[i], record directive marks found in vertical material
     used as directives[i]>
    directives[i] = directives[i-1]  (* Main case *)  OR
    nonmonotonous(pagetotal[1], ..., pagetotal[i])
  IF nonmonotonous(pagetotal[1], ..., pagetotal[i]) THEN
    \shipout pagetry[i-1]
    \shipout pagetry[i]

(*) Or more precisely sum of subcolumn heights, when there are middle 

Lars Hellström