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

Reply via email to