[PATCH 10/25] doc: preserve whitespace by using docbook screen tag

[Nis Martensen]

Using the programlisting tag is not appropriate everywhere. Use the
screen tag where the formatting shall be preserved and the text is no
code listing.

Also add whitespace to prevent gtk-doc from inserting paragraph breaks.
---
 src/cairo-pattern.c |    4 ++--
 src/cairo-version.c |   18 +++++++++---------
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/cairo-pattern.c b/src/cairo-pattern.c
index eaf3c57..205dfe0 100644
--- a/src/cairo-pattern.c
+++ b/src/cairo-pattern.c
@@ -878,7 +878,7 @@ static const int mesh_control_point_j[4] = { 1, 2, 2, 1 };
  * Degenerate sides are permitted so straight lines may be used. A
  * zero length line on one side may be used to create 3 sided patches.
  *
- * <informalexample><programlisting>
+ * <informalexample><screen>
  *       C1     Side 1       C2
  *        +---------------+
  *        |               |
@@ -891,7 +891,7 @@ static const int mesh_control_point_j[4] = { 1, 2, 2, 1 };
  *        |               |
  *        +---------------+
  *      C0     Side 3        C3
- * </programlisting></informalexample>
+ * </screen></informalexample>
  *
  * Each patch is constructed by first calling
  * cairo_mesh_pattern_begin_patch(), then cairo_mesh_pattern_move_to()
diff --git a/src/cairo-version.c b/src/cairo-version.c
index 2f53e11..bc7fe10 100644
--- a/src/cairo-version.c
+++ b/src/cairo-version.c
@@ -54,31 +54,31 @@
  * vs. in-progress development, (such as from git instead of a tar file,
  * or as a "snapshot" tar file as opposed to a "release" tar file).
  *
- * <informalexample><programlisting>
+ * <informalexample><screen>
  *  _____ Major. Always 1, until we invent a new scheme.
  * /  ___ Minor. Even/Odd = Release/Snapshot (tar files) or Branch/Head (git)
  * | /  _ Micro. Even/Odd = Tar-file/git
  * | | /
  * 1.0.0
- * </programlisting></informalexample>
+ * </screen></informalexample>
  *
  * Here are a few examples of versions that one might see.
- * <informalexample><programlisting>
+ * <informalexample><screen>
  * Releases
  * --------
  * 1.0.0 - A major release
  * 1.0.2 - A subsequent maintenance release
  * 1.2.0 - Another major release
- *
+ * &nbsp;
  * Snapshots
  * ---------
  * 1.1.2 - A snapshot (working toward the 1.2.0 release)
- *
+ * &nbsp;
  * In-progress development (eg. from git)
  * --------------------------------------
  * 1.0.1 - Development on a maintenance branch (toward 1.0.2 release)
  * 1.1.1 - Development on head (toward 1.1.2 snapshot and 1.2.0 release)
- * </programlisting></informalexample>
+ * </screen></informalexample>
  * </para>
  * <refsect2>
  * <title>Compatibility</title>
@@ -112,17 +112,17 @@
  * an encoded form suitable for direct comparison. Cairo also provides the
  * macro CAIRO_VERSION_ENCODE() to perform the encoding.
  *
- * <informalexample><programlisting>
+ * <informalexample><screen>
  * Compile-time
  * ------------
  * CAIRO_VERSION_STRING    Human-readable
  * CAIRO_VERSION           Encoded, suitable for comparison
- *
+ * &nbsp;
  * Run-time
  * --------
  * cairo_version_string()  Human-readable
  * cairo_version()         Encoded, suitable for comparison
- * </programlisting></informalexample>
+ * </screen></informalexample>
  *
  * For example, checking that the cairo version is greater than or equal
  * to 1.0.0 could be achieved at compile-time or run-time as follows:
-- 
1.7.2.5


--------------090104080009020304000505
Content-Type: text/plain;
 name="0011-doc-symbol-names-in-header-and-comment-must-match.patch.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0011-doc-symbol-names-in-header-and-comment-must-match.patch";
 filename*1=".txt"