Hello Ivan,
If I remember correctly, moving all<indexterm> instances into their corresponding<title> instances should do the trick. Like this:
Thanks much! I'll give that a try, and will let the list know if it did the trick.
Cheers, STefan
<section id="mcm-install-cluster-creating"> <title>Creating a MySQL Cluster with&mcm; <indexterm> <primary>clusters</primary> <secondary>creating</secondary> </indexterm> </title> <para> In this section, we discuss the procedure for using&mcm; ... On Thu, Nov 3, 2011 at 6:13 PM, Stefan Hinz<[email protected]> wrote:Need a kick in the right direction how to debug/address a problem with orphans. Headings (chapter and section titles) that show up as the last line on a page are among the most annoying things in the widows and orphans space. Text processors will usually implement a rule like "move the heading to the next page when it's followed by less than 3 paragraph lines". DocBook doesn't seem to have a way to implement a similar rule, because "the DocBook DTD does not contain any elements or attributes that control page breaking". However, I found this: "The DocBook XSL stylesheet tries hard to prevent bad page breaks in print output. It assigns keep-together properties to some output blocks, which prevents insertion of a page break within the block. For example, a table with this property will be pushed to the next page if the whole table does not fit at the bottom of a page. For other blocks the stylesheet adds a keep-with-next property to keep the block with the following block. This is useful for section titles so they do not appear at the bottom of a page with nothing after them. -- Note: The previous version of FOP (0.20.5) did not support these keep properties. Be sure to use FOP 0.93 or higher." (http://www.sagehill.net/docbookxsl/PageBreaking.html#SoftPageBreaks) However, in a fairly small document (95 pages in PDF/US Letter), I found five instances of<section> titles that appeared as the last line of a page. The DocBook for all of them looks similar to this: <section id="mcm-install-cluster-creating"> <title>Creating a MySQL Cluster with&mcm;</title> <indexterm> <primary>clusters</primary> <secondary>creating</secondary> </indexterm> <para> In this section, we discuss the procedure for using&mcm; ... Could it be that the<indexterm> container is considered a block, and the style sheet keeps this (invisible) block together with the title, thus finding it in order to put the "next block" (the<para>) on the subsequent page? If so, is there a workaround other than moving the<indexterm> block further below (ugly from a maintenance standpoint)? If not, what's the likely cause of the rendering issue? Thanks in advance for any pointers! -- Cheers, Stefan Hinz<[email protected]>, MySQL Documentation Manager Phone: +49-30-82702940, Fax: +49-30-82702941, http://dev.mysql.com/doc ORACLE Deutschland B.V.& Co. KG Registered Office: Riesstr. 25, 80992 Muenchen, Germany Commercial Register: Local Court Of Munich, HRA 95603 General Partner: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Register Of Chamber Of Commerce: Midden-Niederlande, No. 30143697 Managing Directors: Juergen Kunz, Marcel van de Molen, Alexander van der Ven --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
-- Cheers, Stefan Hinz <[email protected]>, MySQL Documentation Manager Phone: +49-30-82702940, Fax: +49-30-82702941, http://dev.mysql.com/doc ORACLE Deutschland B.V.& Co. KG Registered Office: Riesstr. 25, 80992 Muenchen, Germany Commercial Register: Local Court Of Munich, HRA 95603 General Partner: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Register Of Chamber Of Commerce: Midden-Niederlande, No. 30143697 Managing Directors: Juergen Kunz, Marcel van de Molen, Alexander van der Ven --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
