I'm not very coherent about this either, because I haven't yet developed
a good feel for it, but I will put down some random low-level responses.
   I have just seen your response to Karen, but have not had time to try
to digest that yet.

I think that at some level, the flows can be composed into a line-area
galley (to go back to Karen's original term.)  That galley then provides
lines of a given Inline Progression Dimension on demand from a higher
level.  There are three levels of dimensioning: the dimensions of inline
components, including idividual characters and higher level constructs
of any kind; the IPDimension of a complete line, and the Block
Progression Dimension of a complete line.  If the inline items are
marshalled into a galley, the first level of dimensioning can be
determined and associated with the galley.  When a IPD is determined and
fed back to the galley, the line break and any adjustments (hyphenation,
glyph coalescing) can be made, possibly in a way that simply refers back
to the galley stream.  Once the IPD is determined, the BPD can be

When an area is fed upwards into the layout manager from, say, the
galley, it should be accompanied by a list of possible BPDimension
requirements.  At the simplest level there may be only one; at another
level the list may contain the equivalent of minimum, optimal and
maximum BPDimension to accommodate vertical distribution of lines.  When
a line-area contains a footnote reference, it could be the returning
line area that specifies the space required by the associated footnote,
after asking the question of the footnote galley.  The possibilities
then include 1) postpone the footnote, 2) a single line of the footnote,
3) the separator and a single line of the footnote, 4) all the lines of
the footnote, with or without separator.

While the layout manager still has to distribute the appropriate
line-areas, it has a single point of decision as to what will be laid
out in association with this next line-area, based solely on the
available space.

When the layout manager makes a decision it feeds that decision back to
the galley, which realizes one of the options provided by 1) feeding up
any allowed body text line, and 2) notifying the footnote galley of the
decision about footnotes.  A variant of this would be on the first line
of a new page, where the line-area layout manager would be aware of any
footnotes which are pending from a previous page.  In this case, the
minimum values for the space required would be the inline-areas required
to flush the pending footnotes.

  From the above, you may see that my get feeling for the way the layout
is handled is not one of laying out then trimming, but of offering
areas to the galleys/flow sets and seeing what possibilities come back,
then having the layout manager choose the set that works "best".  There
may only be one member of this set, but in the case of footnotes there
can be more than one, and in the case of side floats there will most
likely be complications.

I want to read up on floats and think more about floats and multi-column 
pages, but prima facie the approach above would work for multi-columns 
with footnotes with little difference.


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
 > breaking.
 > 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.
 > Regards,
 > Karen
 > Keiron Liddle wrote:
 >>Hi All,
 >>I have written a document describing a possible way that we could 
 >>the layout process (also has some info about user agent).
 >>I am hoping for feedback (particularly from those who have looked at the
 >>layout - Arved, Karen, Peter and others).
 >>It is mostly a description so there still may be some gotchas that I
 >>haven't considered. Hopefully this can provide some impetus to moving
 >>forward with the layout design so we can handle all these requests for
 >>things like keeps, spacing, line breaking (chinese characters), floats,
 >>large images, infinite loops etc. For those new to this area handlng 
a lot
 >>of these things is difficult with the current layout process in fop, 
 >>the need for a new approach.
 > ---------------------------------------------------------------------
 > To unsubscribe, e-mail: [EMAIL PROTECTED]
 > For additional commands, email: [EMAIL PROTECTED]

"Lord, to whom shall we go?"

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

Reply via email to