1. SCons
  2. Core
  3. SCons


SCons / src / engine / SCons / Tool / docbook / docbook-xsl-1.76.1 / params / section.container.element.xml

<refentry xmlns="http://docbook.org/ns/docbook"
          version="5.0" xml:id="section.container.element">
<refmiscinfo class="other" otherclass="datatype">list</refmiscinfo>
<refmiscinfo class="other" otherclass="value">block</refmiscinfo>
<refmiscinfo class="other" otherclass="value">wrapper</refmiscinfo>
<refpurpose>Select XSL-FO element name to contain sections</refpurpose>

<src:fragment xml:id="section.container.element.frag">
<xsl:param name="section.container.element">block</xsl:param>


<para>Selects the element name for outer container of
each section. The choices are <literal>block</literal> (default)
or <literal>wrapper</literal>.
The <literal>fo:</literal> namespace prefix is added
by the stylesheet to form the full element name.

<para>This element receives the section <literal>id</literal>
attribute and the appropriate section level attribute-set.

<para>Changing this parameter to <literal>wrapper</literal>
is only necessary when producing multi-column output
that contains page-wide spans.  Using <literal>fo:wrapper</literal>
avoids the nesting of <literal>fo:block</literal>
elements that prevents spans from working (the standard says
a span must be on a block that is a direct child of 

<para>If set to <literal>wrapper</literal>, the
section attribute-sets only support properties
that are inheritable.  That's because there is no
block to apply them to.  Properties such as
font-family are inheritable, but properties such as
border are not.

<para>Only some XSL-FO processors need to use this parameter.
The Antenna House processor, for example, will handle 
spans in nested blocks without changing the element name.
The RenderX XEP product and FOP follow the XSL-FO standard 
and need to use <literal>wrapper</literal>.