Such an entry point sounds quite difficult to me. I'm not sure if we'd be able to come up with anything worthwhile. We'd also need a use case or two. I can't think of any right now. What can be done is to replace a LM with a different implementation. However, I don't know of anyone who has done that, yet. In the case at hand, I think this can simply be handled in our own LMs as optional, non-standard hints for FOP. I don't know how I would implement this feature using some plug-in of a sort.
But if anyone has some cool ideas, I'm all ears... On 10.08.2006 21:09:31 Andreas L Delmelle wrote: > On Aug 10, 2006, at 17:47, Jeremias Maerki wrote: > > > <snip /> > > I could imagine properties like orphan-height and widow-height on > > fo:table and fo:list-block for that purpose. > > That indeed sounds like a job for extension properties. > > I have always wondered what would need to be done to implement an > arbitrary extension property that has an impact on layout... IIC, > there has been talk, way back when, about setting parameters for the > Knuth algorithm through extension properties. > > AFAICT, the foreign attribute is handled when the FO tree is built. > If the namespace is registered as non-ignorable, then it is added to > the FObj, and fully accessible. The framework is in place. Of course, > we are at liberty to implement the use of those foreign attributes > *in* the current table/list LMs, but what would someone have to do if > he/she wants to make it a literal extension...? > > Do we already provide an 'entry point' into the layout API that any > code related to extension properties can use? If not, then this seems > like a perfect opportunity to think about how it should look like. > > > > Cheers, > > Andreas Jeremias Maerki
