Hi Andreas, Andreas L Delmelle wrote: > On Dec 14, 2007, at 11:44, Vincent Hennebert wrote: > >> >> Normally not. The code dealing with border resolution is only triggered >> for tables which are not descendants of a marker (there are !inMarker() >> guards wherever needed —which as some point will need to be replaced by >> something more elegant). > > I wonder what could be a more elegant approach. Do you have any specific > ideas yet, or is this just a nagging feeling? (Believe me, I know those > ;-))
Yes, well, I sometimes wish the code would use more object-oriented approaches... Or perhaps it’s just me getting old ;-) I quite agree with the big picture, but I don’t like having to put “if (!inMarker)” statements everywhere in the code. That makes it more complicated, and it’s dangerous as we can easily forget one somewhere. I’d rather use some kind of intermediate object that will stick to recording children elements without doing anything else. And the proper FObj instances would be created at the retrieval of the markers. But so far I haven’t taken much time to think about it, and validate and implement any likewise approach. > The idea is not only to make the implementation more correct. For > instance, dealing with property-resolution if and when it is needed, > leads to a more correct implementation of inherited properties, relative > font-sizes, percentages, etc. in case of fo:markers. Another cool > advantage is that, for documents with a lot of markers, the savings on > processing time should be significantly reduced if only a fraction of > the markers actually gets retrieved. (A small disadvantage if one single > fo:marker gets retrieved multiple times into an identical context... And no validation is performed on a marker’s children while they aren’t retrieved. Which may make a single document suddenly fail months after the production tool chain has been set up. > Then again, IIC, there is currently no caching going on whatsoever when > it comes to static-contents. This might be something worth considering: > re-use a StaticContentLM's element-list and re-run it through the > algorithm after substituting the sublists corresponding to retrieved > markers.) Well that’s another topic. Sorry, not enough energy to dive in... <snip/> >>> Borders are also not inherited >> >> They are, in one case: when using the "inherit" keyword. > > ... and this should be graciously handled by the deferral of all > property resolution for marker-descendants. Right. Cheers, Vincent -- Vincent Hennebert Anyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
