[xiph-commits] r10466 - trunk/vorbis/doc/xml

[giles at svn.xiph.org]

Author: giles
Date: 2005-11-27 16:34:44 -0800 (Sun, 27 Nov 2005)
New Revision: 10466

Modified:
   trunk/vorbis/doc/xml/04-codec.xml
   trunk/vorbis/doc/xml/07-floor1.xml
   trunk/vorbis/doc/xml/08-residue.xml
Log:
Wrap itemizedlist tags in a para container. Docbook doesn't require 
this, but google alleges it may help with some stylesheet problems
we're having. Doesn't seem to, but doesn't really do any harm either:
we weren't being consistent.


Modified: trunk/vorbis/doc/xml/04-codec.xml
===================================================================
--- trunk/vorbis/doc/xml/04-codec.xml	2005-11-28 00:33:05 UTC (rev 10465)
+++ trunk/vorbis/doc/xml/04-codec.xml	2005-11-28 00:34:44 UTC (rev 10466)
@@ -90,12 +90,14 @@
 field especially may be considerably off in purely VBR streams.  The
 fields are meaningful only when greater than zero.</para>
 
+<para>
 <itemizedlist>
   <listitem><simpara>All three fields set to the same value implies a fixed rate, or tightly bounded, nearly fixed-rate bitstream</simpara></listitem>
   <listitem><simpara>Only nominal set implies a VBR or ABR stream that averages the nominal bitrate</simpara></listitem>
   <listitem><simpara>Maximum and or minimum set implies a VBR bitstream that obeys the bitrate limits</simpara></listitem>
   <listitem><simpara>None set indicates the encoder does not care to speculate.</simpara></listitem>
 </itemizedlist>
+</para>
 
 </section>
 

Modified: trunk/vorbis/doc/xml/07-floor1.xml
===================================================================
--- trunk/vorbis/doc/xml/07-floor1.xml	2005-11-28 00:33:05 UTC (rev 10465)
+++ trunk/vorbis/doc/xml/07-floor1.xml	2005-11-28 00:34:44 UTC (rev 10466)
@@ -35,6 +35,7 @@
 prediction in a process roughly equivalent to the following simplified
 description:</para>
 
+<para>
 <itemizedlist>
  <listitem><simpara> the first line segment (base case) is a logical line spanning
 from x_0,y_0 to x_1,y_1 where in the base case x_0=0 and x_1=[n], the
@@ -56,6 +57,7 @@
 is completed at the end of the x value list.</simpara></listitem>
 
 </itemizedlist>
+</para>
 
 <para>
 Consider the following example, with values chosen for ease of

Modified: trunk/vorbis/doc/xml/08-residue.xml
===================================================================
--- trunk/vorbis/doc/xml/08-residue.xml	2005-11-28 00:33:05 UTC (rev 10465)
+++ trunk/vorbis/doc/xml/08-residue.xml	2005-11-28 00:34:44 UTC (rev 10466)
@@ -50,6 +50,7 @@
 coding structure, ignoring for the moment exactly how a partition is
 encoded and simply trusting that it is, is as follows:</para>
 
+<para>
 <itemizedlist>
 <listitem><para>Each vector is partitioned into multiple equal sized chunks
 according to configuration specified.  If we have a vector size of
@@ -81,6 +82,7 @@
 is coded only in the first pass.</para></listitem>
 
 </itemizedlist>
+</para>
 
 <mediaobject>
 <imageobject>
@@ -362,11 +364,13 @@
 'Residue Format: residue 0' section.  The following pseudocode
 presents the same algorithm. Assume:</para>
 
+<para>
 <itemizedlist>
 <listitem><simpara> <varname>[n]</varname> is the value in <varname>[residue_partition_size]</varname></simpara></listitem>
 <listitem><simpara><varname>[v]</varname> is the residue vector</simpara></listitem>
 <listitem><simpara><varname>[offset]</varname> is the beginning read offset in [v]</simpara></listitem>
 </itemizedlist>
+</para>
 
 <programlisting>
  1) [step] = [n] / [codebook_dimensions]
@@ -396,12 +400,14 @@
 'Residue Format: residue 1' section.  The following pseudocode
 presents the same algorithm. Assume:</para>
 
+<para>
 <itemizedlist>
 <listitem><simpara> <varname>[n]</varname> is the value in
 <varname>[residue_partition_size]</varname></simpara></listitem>
 <listitem><simpara><varname>[v]</varname> is the residue vector</simpara></listitem>
 <listitem><simpara><varname>[offset]</varname> is the beginning read offset in [v]</simpara></listitem>
 </itemizedlist>
+</para>
 
 <programlisting>
  1) [i] = 0