Description of Problem: Version-Release number of selected component (if applicable): How Reproducible: Steps to Reproduce: 1. 2. 3. Actual Results: Expected Results: Additional Information:
Sorry. Apparently pressing enter in the summary text field submits the bug! Anyway, having <para> Exceptions are represented in two ways: <itemizedlist> <listitem> <para>As a single bit (exception present/absent) with these bits corresponding in some implementation-defined way with bit positions in an integer.</para> </listitem> </itemizedlist> <itemizedlist> <listitem> <para>As an opaque structure that may contain more information about the exception (for example, the code address where it occurred).</para> </listitem> </itemizedlist> </para> produces Exceptions are represented in two ways: .TP 3 \(bu As a single bit (exception present/absent) with these bits corresponding in some implementation-defined way with bit positions in an integer. .LP .TP 3 \(bu As an opaque structure that may contain more information about the exception (for example, the code address where it occurred). .LP
Should be fixed in xmlto-0.0.7-1, although it's kinda hacky. I can't think of a _good_ way of fixing it. Do the lists have to be inside the paras?
Lists don't have to be inside paras, but since it is a valid markup I thought it should be fixed. In general, lists should not be put inside paras because it leaves unnecessary white space in the PS/PDF output.