Re: [docbook-apps] programlisting page breaks

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

Hi David,
It sounds reasonable for those with long program listings, but maybe not for those who 
don't.
I guess I would like to hear from more people on the list about making this change. If 
a lot of people are relying on the default keep setting for examples, then changing it 
will force them to update their stylesheet to restore the keeps. If it is anywhere 
near half that want the change and half that don't, then I can't see making the 
change.

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 12:54 PM
Subject: Re: [docbook-apps] programlisting page breaks


> Ok, in that case, the solution is to make keep-together="auto" in example.properties 
> the default since example/programlisting is a fairly common construct. I don't see 
> that keep-together="always" is a problem with figures or equations. Does that sound 
> reasonable?
>
> Thanks,
> David
>
> On 03/09/2011 12:04 PM, Bob Stayton wrote:
>> 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
>
>
>