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 way,
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 creates
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 this
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 area
(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 areas
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 width
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 float
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 difficult.
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 float/footnote
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, then
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
> 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

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

Reply via email to