The fop dependency in the pom.xml for the latest version of that project is
for v1.1: https://code.google.com/p/docbkx-tools/source/browse/trunk/pom.xml.
If you're using the latest version of the plugin, that shouldn't be a
problem. I see some mention of similar sounding bugs in earlier versions of
FOP though.

Can you find the <fo:block that's enclosing that orderedlist in the FO
file? The FO file is an intermediate step in the build so it's likely one
of several files that are usually discarded. The attributes of the
surrounding fo:block might give a clue. Or at least I could compare it to
my FO attributes.

Peter





On Wed, Jul 29, 2015 at 12:59 PM, Janice Manwiller <[email protected]> wrote:

> We use the maven docbkx plugin - all docs are generated using the build
> process. According to their doc, they use Apache FOP for PDF generation.
> They don't give a version.
>
> I haven't made any customizations at all to ordered lists or list items.
> The only keep-together customization I added to was to prevent page breaks
> in table rows.
>
> Janice
>
> On Wed, Jul 29, 2015 at 11:28 AM, Peter Desjardins <
> [email protected]> wrote:
>
>> I'm wondering why the last listitem did not break to the next page. Have
>> you applied any customization to the way orderedlists keep-together? Maybe
>> temporarily turn off all your customizations and see what happens to the
>> lists in the default PDF formatting?
>>
>> I have very many lists with listitems that often include multiple para
>> elements, programlistings, and other children. I have never seen any
>> problem with listitems bleeding into page footers and have never needed to
>> apply the dbfo-need processing instruction. So I would expect the
>> correct breaking behavior to be fairly reliable on its own.
>>
>> Maybe your FO processor could be part of the problem? I use Apache FOP
>> 1.1. How is your FO processed?
>>
>> Another troubleshooting technique I have used is to search the FO file
>> produced by DocBook XSLT and find the corresponding elements in there. Some
>> of the attributes on the list or whatever element is containing it might be
>> giving the FO processor instructions that could lead to this situation. I
>> usually open the FO in a text editor and search for some text strings in
>> the content I'm looking for.
>>
>> Good luck!
>>
>> Peter
>>
>>
>>
>> On Tue, Jul 28, 2015 at 9:25 PM, Janice Manwiller <[email protected]>
>> wrote:
>>
>>> I had asked about this issue earlier, and thought I had found a
>>> solution, but unfortunately it's not working reliably.
>>>
>>> On occasion, PDF pages do not break correctly within a list item. If the
>>> list item contains more than one paragraph, then the paragraphs can bleed
>>> into the page footer.
>>>
>>> I had come across the dbfo-need option, which sometimes works, but not
>>> always.
>>>
>>> The attached image shows an example of this happening.
>>>
>>> Here is the source DocBook XML for the same excerpt.
>>>
>>>                     <listitem>
>>>                         <para>To use a column to add a new field to the
>>> source data, in the dropdown
>>>                             list field, type the name of the new field,
>>> then press
>>>                                 <keycap>Enter</keycap>.</para>
>>>                         <informalfigure>
>>>                             <mediaobject>
>>>                                 <imageobject>
>>>                                     <imagedata scale="100"
>>>                                         fileref=
>>> "../img/ui_data_source_job_csv_new_field.png"/>
>>>                                 </imageobject>
>>>                                 <textobject>
>>>                                     <phrase>Entering a new source field
>>> name for a CSV
>>>                                         column</phrase>
>>>                                 </textobject>
>>>                             </mediaobject>
>>>                         </informalfigure>
>>>                         <para>For information on restrictions on field
>>> names, see <xref
>>>                                 linkend="sqrrl-field-name-restrictions"
>>> />.</para>
>>>                         <para>For these new fields, Sqrrl infers the
>>> data type based on the values
>>>                             in the file.</para>
>>>                         <?dbfo-need height="2in" ?>
>>>                         <para>These new fields are not added to the
>>> source definition.</para>
>>>                     </listitem>
>>>                     <listitem>
>>>                         <para>To remove a column from the list, click
>>> its delete icon.</para>
>>>                     </listitem>
>>>                 </orderedlist></para>
>>> So while I have the dbfo-need option set for the paragraph, it's still
>>> not causing the page to break.
>>>
>>> Any ideas to get this to work reliably?
>>>
>>> Thanks,
>>>
>>> Janice
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>
>>
>
>
> --
> Janice Manwiller
> Principal Technical Writer
> Sqrrl Data, Inc.
> www.sqrrl.com | @SqrrlData
>

Reply via email to