I'll only answer a few things.

The before floats should behave fairly similar to footnotes.
I am quite sure that the side floats cannot go outside of the body region
area (and overlap footnotes), anyway that would be rather complicated.

About using the minimum spacing first:
The reason I suggest this is for the situation where there are keeps on
some block areas that go over the end of the page. It is possible that
fitting the blocks on the page using a spacing between min and optimum
would give a closer value to the optimum than putting the blocks on the
next page and the spacing being between optimum and max. So if the objects
are placed first at optimum then you will need to keep going to see if
there is a lower keep further on that has a spacing that is closer to the
optimum. I want to avoid having too many conditional things like this that
may need movement in both directions. This just suggests complications and
infinite loops to me.

On Wed, 05 Sep 2001 16:20:08 Peter B. West wrote:
> Keiron,
> I have read a bit about the floats, particularly the side-floats, and I
> realized that my simple model of footnote generation is completely
> destroyed by the side-floats.  Your comment about doing an initial full
> layout accommodates that problem.  The key, as you say, is determining
> the InlinePDimension at each point in the layout.  (What follows repeats
> a lot of what you have said.  I'm just trying to get hold of the ideas.)
> I like to think of that process as one of backtracking.  Take the
> relationship between footnote and side-float generation.  Go back to the
> idea of having the "inline-flow-sets" produce lines of a given IPD and
> BPD on a demand emanating from a higher level; i.e. break a line out of
> the i-f-set.  The essential item of information for the i-f-set is the
> IPDimension, which must be fed back down from a higher level.  I think
> Jeffrey Kingston talks about this sort of bouncing down-up-down the tree
> in the Lout design document.  I.e., descend the tree to the point where
> the galleys (i-f-sets) are generated, then ascend the tree again to the
> point where the space available for the layout of a particular galley is
> determined.  Send this information back down to the galley process.
> The comments I made about the i-f-s providing a set of possible
> BPDimension requirements back to the layout manager would then still
> hold, on the assumption of a given IPDimension.  Everything goes
> according to plan until a side float is encountered.  The thing about
> side floats, as I read it, is that the IPDimension of the float area is
> intrinsically determined, either by the intrinsic dimensions of, say,
> and image, or by some other characteristics of the children of the
> float.  (In CSS, the float is obliged to either have intrinsic
> dimensions, as for an image, or have the "width" property defined.  What
> happens with FO?  Is it obligatory for "width" to be defined on a child
> or children?  Or can the layout make any kind of width determination it
> sees fit?)  I am assuming that the IPDimension of the float is
> determined independently of what is happening in the normal flow.  The
> result is that, given the basic IPDimension of the area into which a
> side float is introduced, the float can be recursively laid out
> independently in order to determine the IPDimension of the float.  This
> then, in combination with the original IPDimension of the main reference
> area to which the float is being added, gives the reduced IPDimension
> for the lines flowing around the float.
> My other assumption, the validity of which I do no know, is that the
> side float can only be placed within the main reference area.  That is,
> it is not allowed to intrude on the footnote area.  I cannot easily see
> whether this is true, but if it is not, the consequences do not bear
> thinking on.  The IPDimension for footnotes would vary with the presence
> of side-floats; side-floats could intrude part-way into the footnote
> reference area; when they did, each new footnote would initially have an
> IPDimension equal to the corresponding main reference area IPD without
> intrusions, but would push older footnotes into the intrusion area at
> the top of the footnote reference area.
> Before detecting side float:
> ============================
> bbb bbbb bb bbbbbb(1) bb bbb
> bbbb bb bbbb bbb
> ....
> ....
> ....
> ----------------------------
> 1 Footnote 1 originally to
>     full width of the parent
>     reference area
> After detecting side float:
> ===========================
> bbb bbbb bb bbbbbb(1) bb bbb
> bbbb bb bbbb bbb
> ....
> ....
> ---------+
> fff ff ff|bbb bb(2) bbbb b
> ff fffff |------------------
> ffff f ff|1 Footnote 1 orig-
> ---------+  ally to full
> width of the parent refer-
> ence area
> 2 Footnote 2  - a new foot-
>     note
> Given those two assumptions, when the float is encountered, it
> presumably does not alter the relationship between any line in which a
> footnote has already been encountered and the end of the available BP
> space between that line and the end of the main-reference-area.  That
> is, the information fed back by the i-f-set about minimum-maximum space
> requirements in the presence of the footnote body generated on that line
> is still valid.  This because the IPDimension of the footnote reference
> area, under the above assumptions, does not change.
> What the presence of a side float may do, however, is alter which of
> those options the layout manager may choose.  That is, the appearance of
> a side-float may, because of the BPDimension depth of the float,
> restrict the upward (in the Block Progression direction) growth of the
> footnote reference area, and oblige the layout manager to push more of
> the footnote text onto the next page
> Before detection of float:
> ==========================
> bbb bbbb bb bbbbbb(1) bb bbb
> bbbb bb bbbb bbb bbbbbb bb
> bbbbbbb
> (available area
>    of page)
> ----------------------------
> 1 Footnote 1 originally to
>     full width of the parent
>     reference area
> After detection of float:
> ========================
> bbb bbbb bb bbbbbb(1) bb bbb
> bbbb bb bbbb bbb bbbbbb bb
> ----------+bbbbbbb bb(A) bbbb
> ff ffff ff|bbbb bb bbb bb
> f fff ffff|bbbb bbbbbbbb b
> fffff ff  | bbb bb bbb
> ----------+
> ----------------------------
> 1 Footnote 1 originally to
> (Remainder forced onto next page)
> It seems to me that handling this situation could be done by
> backtracking within the page.  When a side float is encountered, lay out
> the float (independently) and determine its impact on the IPDimension of
> the column.  Now backtrack to the point of the first footnote on the
> page, and reassess the footnote decisions based on the possibly reduced
> availibility of BP space.  None of the line break decisions so far
> taken, and none of the minimum-maximum BP space requirements (which take
> account of footnote requirements) for lines so far examined, need to be
> changed.  The side float will only affect line break decisions farther
> on in the text.
> On the point of using minimum/optimum in the layout, I would lean to
> using the optimum, and only backtracking to try something else when
> difficulties were encountered.
> I haven't thought about the impact of before floats at all.
> Peter

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to