Keiron,
I thought it would be better to start a new thread.
I've continued the discussion below.
Keiron Liddle wrote:
>
> Hi Karen,
>
> Its seems that there are gotcha's no matter what direction we take.
+1 :-)
> I will try to present the reasons behind the approach I am taking.
> I welcome your input and I will look at the code to see how your code
> works.
>
> It seems we need a set of "tough cases" that we need to be able to handle
> to be confident of the correct approach.
Agreed.
> So why flatten the inline layout managers?
> If we have an example like this:
>
> <block>Some text <basic-link>a paragraph of text<block>with a
> block</block>and more text</basic-link> and <inline background="blue">blue
> background<inline color="green"> green text <block>a block</block> more
> green</inline></inline></block>
>
> The basic link produces/returns both inline areas and a block area, so it
> is not possible to say that the basic-link element or its layout manager
> would produce inline areas. So how should this be handled. If it is
> flattened things are easier. The layout manager can then keep range
> information like: starts link, ends link.
It's certainly true that mixing blocks in inlines, as the spec says is
allowed, gets very complicated. I remember some discussion of this on
the list a long while ago and I think we actually asked the XSL editors
what kind of areas they imagined this generating, but never got an
answer. If I understand your idea correctly, the layout areas you would
generate from this example are the ones I would like to generate also.
(Block area containing some lines, nested block, more lines, nested
block and more lines.)
I will work on a bit of pseudo-code showing how the nesting approach
would do it (or not do it).
> Determining line breaks:
> <block>text on a hyphenated line with a col<inline
> color="red">our</inline>ed word</block>
> In this case the text layout manager cannot determine a break after "col",
> only the line layout manager can work out a suitable break point or
> hyphenation. (I don't know what your code does but this is why I simply
> get areas from the text layout manager)
Right, I know about this case. That's handled in status flags that I
pass back in the BreakPoss object which say if it's really possible to
break after the returned position. When a break represents the end of an
FO's content ("col" for example) and it doesn't end on a space or some
other potential line-end character, the flags is set to indicate that
this isn't a legal breakpoint. So the Line (or Inline level) LM will
keep asking for more BreakPoss until it gets one where it can break
(after "ed" in your example). Then it will see if can fit that into the
available space. If it can't, it will try to hyphenate "coloured". I
thought that through some while back but didn't actually write code. It
has to collect the characters from all the layout managers which
contributed to the "word", whatever their level, do the hyphenation, and
then figure out which LM was responsible for the part containing the
hyphen. Obviously rather complicated, but this is one of those difficult
test cases.
For now, I didn't even commit the inline stacking LM, but it's basically
a simplified version of LineBPLayoutManager. It never tries to figure
out whether a BreakPoss returned by one of its child LM actually fits,
it just "wraps" it with its own space requirements and returns that to
its parent.
> 1&2. This is the idea of the range properties. I can see how putting
> everything in a single inline area could be useful as long as other things
> are easily transparent.
> I was thinking of getting this information from the inline layout managers
> so that the line layout manager can deal with it appropriately.
OK, I figured I had overlooked something. I see you addressed this in
your mail with start and end properties. Would it be fair to think of
these as some kind of "layout control characters" at the text level?
Since I started working on FOP, I've thought of lots of schemes to try
to correctly handle the space information at different tree levels,
especially in combination with conditional space, border and padding. I
never came up with a good way of doing it using the flat model, but that
doesn't mean there isn't one. I'll have to think through how these
properties would be used and whether they will handle the hard test
cases like a couple of levels of nested inlines with various
space-start/space-end and borders. We'll basically have the same issues
with block-level LM in any case, except that it's more common to nest at
that level. Especially since users often tend to reflect the nesting of
their original XML document in the FO they generate.
*** I think this is clearly the key issue to decide in this round of
discussions: flattened or nested.
> 3. Ideally the layout process should start as soon as the first block is
> ended (no matter how deep it is). So something like, when starting a block
> level element the layout manager is added to the parent, when a block
> level element is ended then the layout process starts and adds the areas
> from that block etc.
> How this will happen in practice I haven't really thought about. If the
> iterator can do that then we should use it.
That's my theory too. I think an iterator over the child LayoutManagers
(which is more or less an interator over the child FOs), can be written
to get the next child if available and if not to "wait" (the consumer
thread). It would then be awakened by the thread building the FO tree
(the producer) when it had completed a block-level FOnode. There needs
to be something indicating when an FO is complete so the consumer will
not be eternally waiting on more children to arrive!
> On 2002.04.29 00:16 Karen Lease wrote:
> > Hi Keiron,
> >
> > Here are a few comments on your new layoutmgr stuff (which is definitely
> > more advanced than mine in most ways) :
> >
> > 1. I can't figure out how/where you manage space-start, space-end,
> > border, padding, background etc (ie, any non-inherited properties) for
> > non leaf node inline FO, ie: fo:inline and fo:basic-link. As you said,
> > you're "flattening" the inline LM, so in fact, you're just adding the FO
> > children of the inline. I think that if these FO _must_ create real
> > inline areas if they have any non-inherited properties. If they don't
> > they are acting kind of like fo:wrapper, and in that case, I agree we
> > don't need a separate layout manager, because no area needs to be
> > created.
> >
> > For basic-link, I think it would also be easier if it created an inline
> > area containing its child areas even if it doesn't have any
> > non-ineritable layout type properites. We could hang the linking
> > information on that area (or areas, if it split across lines).
> >
> > But if we make nested inline areas, then the space adjustment as written
> > in the LineLayoutManager won't work correctly, because it won't see the
> > nested spaces.
> >
> > 2. Lack of context information: I ended up adding a LayoutContext oject
> > to pass information down to the LM(s) generating the areas. This is to
> > handle things like space-specifiers which can accumulate from various
> > tree levels, and also to indicate when a LM is generating a break (or an
> > Area) which is first in its parent area. That can influence things like
> > conditional space and borders and padding. What's a pain with that stuff
> > is that it changes the IPD, so until we know where the area is going to
> > be placed, we don't know exactly how big it will be.
> >
> > 3. I'd like to avoid having to generate all the child LM before starting
> > to layout any given level. This would limit us to waiting for a whole
> > fo:flow to be done (unless we special case at that level). I think we
> > can find a way to "pull" on the layout managers and still keep the
> > flexibility you gain with the addLayoutManager(List) approach. I think
> > it could be done with some kind of Iterator. (OK, I'm on kind of an
> > Iterator fling recently, but they _are_ really handy. :-)
> >
> > Regards,
> > Karen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
