On Sat, 20 Aug 2005 11:33 pm, Jeremias Maerki wrote:
> Looks like you made a thorough analysis. What I read made sense to me
> although I didn't check everything to the last character. Providing
> the Context interface through the LayoutContext didn't occur to me
> and I don't know if it's the right way, but if it just clicks in
> there without much hassle then it's probably a good idea. I'd have
> implemented the Context as an inner class to the LMs but then I
> haven't investigated this so thoroughly as you just did. I simply
> stumbled over it back in January and what I wrote there was simply
> what was occuring to me at the time (having been a newbie to the
> layout engine, too, back then).
>
> So. I believe you're on the right course. Your approach seems to be
> fine-grained enough to handle every case and still limit the
> additional code to where it is needed.
I have been working on this for the last couple of days and I am not so
sure any more about the 'being on the right course' bit. So this is a
bit of a cry for feedback. I will try to outline the issues.
Most percentages are being resolved in the same way: Find the
appropriate ancestor area and get the relevant dimension from it. That
sounds very simple. The current system solves this by a) using the fo
tree to navigate upwards until an appropriate fo is found which
generates the type of area we are looking for and b) by the layout
managers to attach dimension information to the fos. The reason we are
looking for a redesign is that this doesn't appear to be the right way
to attach layout information to the fos. The current system is also not
complete in its implementation but that is a different issue.
The alternative proposed is to use a context which is created by the
layout managers and passed to the property resolution system, i.e. the
getValue() call. Sounds good so far as the layout managers have access
to the dimension information, actually in my code in the moment the
layout managers are the context, that is they implement the interface I
have defined for the context. But we still need to move up some form of
tree or list to find ancestors. The obvious choice would be the area
tree but that doesn't work as in many cases when we need a resolved
property value the areas (as objects in fop) haven't been created yet.
Also the areas are not linked back upwards in the tree although a
parent pointer could be introduced for that purpose. So, if we can't
use the area tree and don't want to use the fo tree what then? The next
thing coming to mind is the layout managers as they form a tree
structure as well. They even have a parent pointer. So, to find the
dimensions we are looking for we navigate up the parent links of the
layout managers until we find one which generates what we are looking
for and get the dimensions from it. But, the parent link is not set
consistently and sometimes late. There is for example the case where a
layout manager in its constructor accesses a property value. To be able
to resolve it would need to know its parent layout manager which isn't
set yet. The fix for that is to carry the parent layout manager into
all layout manager constructors.
This is where my problem is. We have a system now which is simple
(attach dimension information to the fo tree) and we are replacing it
with something that changes many internal interfaces, virtually
hundreds of method calls by adding extra parameters, and still does the
same thing. Navigate up a tree structure (and I am not 100% sure that
navigating up the layout manager tree really is the right thing to do)
to find a suitable node and get the appropriate values from that node.
At the moment I believe both systems can be made to work but I am not so
sure any more that the new system is actually better. Shall I continue
on the current path or shall I revert back to the original system and
complete its implementation?
I don't know (and have a cold and a headache to aggravate the situation)
- any insights, help, suggestions are much appreciated.
Manuel
> This is going to be a big jump
> into the layout engine for you. I'm glad you want to try it. Please
> don't forget to document your work with test cases ("test-first" has
> proven to be very helpful while I'm coding in FOP's layout engine).
> I'm looking forward to reviewing you patch. And thanks so much for
> your help!!!
>
> BTW, I'm very positively surprised and extremely pleased about your
> contributions so far. Is your boss supporting you or have you simply
> become addicted to FOP? :-) Just curious.
>
> On 19.08.2005 17:58:48 Manuel Mall wrote:
> > I have just documented the rules with respect to determining the
> > base value for percentage calculations on the WIKI [1]. I also
> > looked at the fop-dev messages related to the code in this area
> > ([2] and [3]).
> >
> > If my analysis in [1] is correct we have broadly speaking 4
> > different cases to consider:
> >
> > 1) Percentages resolved against property values (mainly font-size)
> > in the fo tree. That is the "easy" case and can be done during fo
> > tree construction similar to some other relative properties. This
> > would get rid of the need to carry the property lists into the
> > LengthBase (see [3]).
> >
> > 2) Percentages resolved against dimensions (ipd, bpd, padding
> > rectangle, etc.) in the area tree (current area, parent area,
> > ancestor block, etc.). This is the "hard" case - discussion below.
> >
> > 3) Special case dealing with intrinsic sizes of e-g and i-f-o (2
> > properties). This could be handled "locally".
> >
> > 4) Special case for resolution against region (1 property). Again
> > this could be handled locally.
> >
> > [2] deals with the case 2) above and problems in the current
> > system. The current system uses the fo tree to simulate upwards
> > navigation through the areas. It is the LMs responsibility to add
> > dimension information to the FOs which is then used for percentage
> > resolution. The alternative proposed is for the LMs to construct a
> > "context" object which is passed to the property getValue()
> > function. This context object (working name
> > PropertyResolutionContext) will provide the means for the property
> > resolution code to get to the relevant dimensions, e.g. provide
> > getters like getParentAreaIPB(), getContainingBlockBPD(),
> > getIntrinsicHeight(), .... The context object internally could make
> > use of the information stored in the current LayoutContext (may be
> > by defining PropertyResolutionContext as an interface LayoutContext
> > can implement it?) as well as in the area tree constructed so far.
> >
> > I'll stop here - does this makes sense so far? Worth pursuing
> > further? Remember I am new to this and be grateful for any
> > 'gotchas' and the like to be pointed out to me.
> >
> > Manuel
> >
> > On Fri, 19 Aug 2005 04:20 pm, Jeremias Maerki wrote:
> > > On 18.08.2005 17:32:54 Manuel Mall wrote:
> > > > I am currently looking at the XSL-FO spec with respect to
> > > > resolving percentages in property values because it was
> > > > mentioned on this list that the current system in FOP needs
> > > > improvements. For many properties the spec refers to the
> > > > 'closest ancestor block area that is not a line area'. This
> > > > again is the same as 'containing block'. However, I also came
> > > > across a description saying 'closest area ancestor that was
> > > > generated by a block-level formatting object'. Now are these
> > > > the same things: 'closest ancestor block area that is not a
> > > > line area' == 'closest area ancestor that was generated by a
> > > > block-level formatting object'? It sounds to me like they are
> > > > the same or do I miss some subtle difference?
> > >
> > > It's probably the same although I can't shake the feeling,
> > > either, that there could be a subtle difference. But I'm pretty
> > > sure that the intent is for it to have the same effect. I think
> > > it boils down to having good test cases which document all the
> > > different
> > > possibilities. Based on these we can in time find out if there
> > > are indeed some differences by looking at each and every case.
> > >
> > > BTW, my original mail to suggest a refactoring of the percentage
> > > handling mechanism (just for reference):
> > > http://marc.theaimsgroup.com/?l=fop-dev&m=110630658730554&w=2
> > >
> > > I don't claim that my proposal is the right way to pursue this
> > > but I still think it probably offers the best flexibility even if
> > > it probably complicates the layout managers a bit.
> > >
> > > Thanks for looking at this. It's on my list but not for just now.
> > >
> > > Jeremias Maerki
> >
> > [1]
> > http://wiki.apache.org/xmlgraphics-fop/PropertyHandling/Percentages
> > [2] http://marc.theaimsgroup.com/?l=fop-dev&m=110630658730554&w=2
> > [3] http://marc.theaimsgroup.com/?l=fop-dev&m=110442946030972&w=2
>
> Jeremias Maerki
