You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/08/10 17:47:26 UTC

widows and orphans on lists and tables

Hey gang,

a client asks me to implement some kind of widow/orphan setting for
lists and tables so that no single list item or table cell is left alone
on a page, if that list item or cell only contains 1 or 2 lines. In
general, you could use keep-with-next and keep-with-previous to hold the
first and last two items/rows together. But if the content is larger
than 2 or 3 lines and you don't really know how big the content is you
will want to use the space better. My client realizes that he can do
some approximation in XSLT but he'd prefer to have FOP do that.
Naturally, this is an extension to XSL-FO.

Instead of counting lines (in case of images, for example), this setting
could also depend on the height of the first/last list item/row, i.e. if
the first row is not higher than 2em keep it together with the second
row. That would make the implementation a lot easier.

I could imagine properties like orphan-height and widow-height on
fo:table and fo:list-block for that purpose.

I hope I was able to explain it. Any thoughts?

Jeremias Maerki


Re: widows and orphans on lists and tables

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
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


Re: widows and orphans on lists and tables

Posted by Andreas L Delmelle <a_...@pandora.be>.
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