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
