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
[email protected]
----- Original Message -----
From: "David Cramer" <[email protected]>
To: <[email protected]>
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
[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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
