Re: [docbook-apps] programlisting page breaks

["Bob Stayton" <bobs@sagehill.net>]

Hi David,
One clarification: tables are not included. The 'table.properties' attribute-set uses 
'formal.object.properties' but then overrides keep-together.within-column to set it to 
'auto'. So we are talking about example, figure, and equation  (and not their informal 
counterparts, nor programlisting).

Bob Stayton
Sagehill Enterprises
bobs@sagehill.net


----- Original Message ----- 
From: "David Cramer" <david@thingbag.net>
To: <docbook-apps@lists.oasis-open.org>
Sent: Wednesday, March 09, 2011 6:43 AM
Subject: Re: [docbook-apps] programlisting page breaks


> So I hit up against this problem and found that, indeed, the keep-together being set 
> to always for formal.object.properties is the cause. To fix it, I've added the 
> following to my customization layer:
>
> <xsl:attribute-set name="formal.object.properties">
> <xsl:attribute name="keep-together.within-column">auto</xsl:attribute>
> </xsl:attribute-set>
>
> The current behavior is described in Bob's book: 
> http://www.sagehill.net/docbookxsl/PageBreaking.html
>
> However, this seems to be a case where the default behavior violates the principle 
> of least surprise. Currently, if you process a document with a table or example that 
> is more than one page long, the results will be unacceptable/stop-ship (but there's 
> no easy way to make the fo renderer stop processing the document when this happens). 
> On the other hand, if we make the default "auto", you might occasionally have a 
> short table or example that's split across pages when it would be better if they 
> were kept together, but the result would still be acceptable. I think it would be 
> better if we set the keep-together for formal objects to "auto" and then let the 
> user add a PI to set it to always if necessary.
>
> Are there arguments against making keep-together="auto" on formal objects the 
> default that I'm not aware of?
>
> Thanks,
> David
>
> On 02/14/2011 09:55 PM, Richard Hamilton wrote:
>> David,
>>
>> Thanks for the information. I'm currently using xep, but a newer (1.76 or so, I'm 
>> away from my computer right nome and don't remember for sure) version of the 
>> stylesheets. I'll look at the fo for a keep-together.
>>
>> Thanks
>> Dick
>>
>>
>>
>> On Feb 15, 2011, at 11:40, "Cramer, David W (David)"<dcramer@motive.com>  wrote:
>>
>>> Hi Dick,
>>> It sounds like what would happen if you have a keep-together on a fo:block around 
>>> the code listing. I'd check for that.
>>>
>>> I also did a quick test with a document that has long code listings: Using XEP and 
>>> our customization layer which is based on the 1.72.0 xsls, everything is fine. 
>>> However, using FOP and the 1.76.1 xsls included in the latest version of Oxygen, 
>>> the long code listings are pretty messed up (even worse than what you describe).
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: hamilton@xmlpress.net [mailto:hamilton@xmlpress.net]
>>> Sent: Monday, February 14, 2011 10:54 AM
>>> To: docbook-apps@lists.oasis-open.org
>>> Subject: [docbook-apps] programlisting page breaks
>>>
>>> I ran into a curious behavior with programlistings, and I wonder if anyone knows 
>>> how to work around it.
>>>
>>> I have some programlistings that are longer than one page and will need to break.
>>>
>>> That's fine, but what's strange is that regardless of where the programlisting 
>>> would naturally start, there is always a page break before the listing starts.
>>>
>>> Even if the text that precedes the programlisting extends only a few lines down a 
>>> page, there will be a page break before the programlisting begins. That can lead 
>>> to there being 2/3 or more of a page blank for no good reason.
>>>
>>> I'll dive into the code at some point, but if anyone has already handled this, I'd 
>>> appreciate pointers, suggestions, or solutions.
>>>
>>> Best Regards,
>>> Dick Hamilton
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>
>
>