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 implement
> 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, hence
> the need for a new approach.
> ...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
