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-

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
(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.


Keiron Liddle wrote:

 > Hi Karen,
 > I think that I haven't explained some things very well. I have all these
 > concepts in my head but its a bit difficult to write it in a coherent 
 > I need more pictures. (Reading it several times sounds like a bad sign :)
 > Yes the IPD is a crucial part of the process.
 > The idea is to first let the page sequence object construct a page layout
 > manager, this page layout manager then grabs managers for all block areas
 > in the flow. At this stage the managers just have a reference to the
 > information no area creation is done.
 > Then the process of laying out a page is started. The page sequence 
 > a page area object, then the block area layout managers are asked to add
 > their block area(s) into the current page (actually span area). So at 
 > stage the layout managers have the page in which the objects are being
 > placed. The idea is that a roughly valid page is created that can then be
 > vertically justified using the layout managers and information in the 
 > (sub)tree.
 > So when a block area is creating a line area it know exactly the width
 > available and adds inline areas until the line is full. Initially the 
 > are added with minimum distance then once a line is full then it is
 > horizontally justified to find the optimum fit. I believe that no matter
 > how deep the block areas are stacked, with things like inline-container,
 > table etc. (side floats get the width from their children?) then the 
 > of the area is always known and can be supplied by the parent manager.
 > If a line area contains a float then it will place the float starting at
 > the current line, then when it comes to justifying the line the available
 > width is reduced by the width of the float. If the float, the inline 
 > anchor and the inline object it is kept with cannot fit on the line then
 > the line is cut short and the float stuff is placed on the next line.
 > For floats inside nested block areas I think it gets a bit more 
 > What should happen for a float inside a table cell, when the table has a
 > percentage value for a table column width. I suppose the easiest solution
 > would be to place the side float in the next reference area.
 > The line area will know about the float (and footnotes) because of the
 > anchor inline area. The block also needs to know what line a 
 > is on. I'm trying to avoid getting into too much detail about where
 > information is kept. Hopefully it is enough to say that when a block area
 > is being split it may need to consider floats/footnotes inside some 
of the
 > lines in the block.
 > Although I am mostly talking about this from the top down I think the
 > actuall implementation will be about placing inline areas into lines, 
 > lines get placed into blocks then blocks into pages. I think that it is
 > easier to consider how to handle floats/footnotes etc from this angle.
 > One area I am really vague about is columns on pages with spanning 
and the
 > balancing (this time I mean multi column page) process.
 > Keiron.
 > On Mon, 03 Sep 2001 23:22:31 Karen Lease wrote:
 >>Hi Keiron,
 >>I have read your design document carefully several times. The layout
 >>manager idea has a familiar ring to it... something I had thought a
 >>bunch about but never formalized as you have done. In essence, it sounds
 >>like it would handle a bunch of stuff that the FO classes themselves are
 >>currently trying to do. I was hesitating about moving more logic into
 >>the areas themselves, but I think your idea of having a "middle
 >>man(ager)" is better.
 >>One attractive idea is that we could start with a fairly basic manager
 >>as you describe, but could perhaps develop more sophisticated ones in
 >>the long term (ie, manager is strategy). Also it's clear that the
 >>manager which is doing line breaking (the Inline Manager?) will exist in
 >>different versions to handle different kinds of writing-modes and styles
 >>(western, CJK...)
 >>I was trying to find a time when I was feeling more coherent to put my
 >>questions and remarks together, but given all the traveling I'm doing
 >>for work that's not happening. So I'll just start here by writing down a
 >>few things that came to mind. Then if I've misunderstood what you meant,
 >>we'll find out sooner.
 >>I think my main concern is to be sure I understand where you are
 >>actually thinking of doing the line building, ie. where the
 >>inline-progression-dimension (IPD for short) of the columns will
 >>actually be determined. Obviously this depends on the selection of the
 >>page master to be used to hold the areas. That's a big part of what
 >>motivated my bottom-up approach.
 >>If the block layout managers (BLM) are actually created before the page
 >>is made, then they can't make lines yet. That is one of the ideas I had
 >>been playing with. In that case the manager is managing one or more
 >>"inline flow sets" which is what I had called a sequence of characters
 >>and other inline content which wasn't yet broken into lines. The BLM
 >>might also manage nested BLM. When the parent manager asks the BLM to
 >>produce an area, it sets the IPD and so the inline flow set can be
 >>broken into lines. In general, all the layout managers need to know the
 >>IPD in order to work. For examples non-fixed table layout depends on it,
 >>leaders, and other expandable content like images which are scaled to
 >>available space. For me this is a key issue.
 >>Also you talk about how floating objects would be removed from the page
 >>while looking for the best break, but you don't talk much about how they
 >>get put on. Are you thinking they will be added at the moment where the
 >>anchor is encountered? They at least have to be queued at that point or
 >>signaled to the page-level LM. You mention that the BLM manages the
 >>anchors. I was thinking of delegating to the LineArea objects
 >>themselves; but obviously the key idea is that something knows about
 >>them since the areas attached to them can move around during page
 >>Just a language issue: you talk of page balancing which makes me think
 >>of balancing a multi-column page above a span or at the end of a flow;
 >>but you seem to be using it to mean optimizing the break and
 >>distributing the resulting vertical space. The term "VJ" for "vertical
 >>justification" is often used for that process.
 >>I like the user-agent idea a lot; it seems like an elegant way to handle
 >>a lot of configuration issues. I remember worrying about that sometime
 >>last year when I started to look at property values like "thin",
 >>"thick", "smaller", etc.
 >>I'm looking forward to continuing the discussion here.

"Lord, to whom shall we go?"

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

Reply via email to