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
[email protected]
----- Original Message ----- From: "David Cramer" <[email protected]>
To: <[email protected]>
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)"<[email protected]> 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: [email protected] [mailto:[email protected]]
Sent: Monday, February 14, 2011 10:54 AM
To: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
