List:Commits« Previous MessageNext Message »
From:paul Date:January 15 2006 4:58am
Subject:svn commit - mysqldoc@docsrva: r837 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-15 05:58:07 +0100 (Sun, 15 Jan 2006)
New Revision: 837

Log:
 r6217@frost:  paul | 2006-01-14 22:13:02 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/charset.xml
   trunk/refman-5.0/charset.xml
   trunk/refman-5.1/charset.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6216
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6217
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2175

Modified: trunk/refman-4.1/charset.xml
===================================================================
--- trunk/refman-4.1/charset.xml	2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-4.1/charset.xml	2006-01-15 04:58:07 UTC (rev 837)
@@ -3178,14 +3178,15 @@
       </indexterm>
 
       <para>
-        The <literal>utf8_unicode_ci</literal> collation is implemented
-        according to the Unicode Collation Algorithm (UCA) described at
+        MySQL implements the <literal>utf8_unicode_ci</literal>
+        collation according to the Unicode Collation Algorithm (UCA)
+        described at
         <ulink url="http://www.unicode.org/reports/tr10/"/>. The
         collation uses the version-4.0.0 UCA weight keys:
         <ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
-        (The following discussion uses
+        The following discussion uses
         <literal>utf8_unicode_ci</literal>, but it is also true for
-        <literal>ucs2_unicode_ci</literal>.)
+        <literal>ucs2_unicode_ci</literal>.
       </para>
 
       <para>
@@ -3212,7 +3213,7 @@
         comparisons between characters. This means that comparisons for
         the <literal>utf8_general_ci</literal> collation are faster, but
         slightly less correct, than comparisons for
-        <literal>utf8_unicode_ci</literal>).
+        <literal>utf8_unicode_ci</literal>.
       </para>
 
       <para>
@@ -3245,8 +3246,8 @@
 </programlisting>
 
       <para>
-        Language-specific collations for the <literal>utf8</literal>
-        character set are implemented only if the ordering with
+        MySQL implements language-specific collations for the
+        <literal>utf8</literal> character set only if the ordering with
         <literal>utf8_unicode_ci</literal> does not work well for a
         language. For example, <literal>utf8_unicode_ci</literal> works
         fine for German and French, so there is no need to create
@@ -3255,7 +3256,7 @@
       </para>
 
       <para>
-        <literal>utf8_general_ci</literal> is also satisfactory for both
+        <literal>utf8_general_ci</literal> also is satisfactory for both
         German and French, except that
         &lsquo;<literal>ß</literal>&rsquo; is equal to
         &lsquo;<literal>s</literal>&rsquo;, and not to
@@ -3398,8 +3399,7 @@
 
         <listitem>
           <para>
-            <literal>latin1</literal> (cp1252 West European) collations
-            (see the annotations about <quote>latin1</quote> below):
+            <literal>latin1</literal> (cp1252 West European) collations:
           </para>
 
           <itemizedlist>
@@ -3455,8 +3455,30 @@
           </itemizedlist>
 
           <para>
-            <literal>latin1</literal> is the default character set. The
-            <literal>latin1_swedish_ci</literal> collation is the
+            <literal>latin1</literal> is the default character set.
+            MySQL's <literal>latin1</literal> is the same as the Windows
+            <literal>cp1252</literal> character set. This means it is
+            the same as the official <literal>ISO 8859-1</literal> or
+            IANA (Internet Assigned Numbers Authority)
+            <literal>latin1</literal>, but IANA
+            <literal>latin1</literal> treats the code points between
+            <literal>0x80</literal> and <literal>0x9f</literal> as
+            <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+            and therefore MySQL's <literal>latin1</literal>, assign
+            characters for those positions. For example,
+            <literal>0x80</literal> is the Euro sign. For the
+            <quote>undefined</quote> entries in
+            <literal>cp1252</literal>, MySQL translates
+            <literal>0x81</literal> to Unicode
+            <literal>0x0081</literal>, <literal>0x8d</literal> to
+            <literal>0x008d</literal>, <literal>0x8f</literal> to
+            <literal>0x008f</literal>, <literal>0x90</literal> to
+            <literal>0x0090</literal>, and <literal>0x9d</literal> to
+            <literal>0x009d</literal>.
+          </para>
+
+          <para>
+            The <literal>latin1_swedish_ci</literal> collation is the
             default that probably is used by the majority of MySQL
             customers. Although it is frequently said that it is based
             on the Swedish/Finnish collation rules, there are Swedes and
@@ -3557,27 +3579,6 @@
 
       </itemizedlist>
 
-      <para>
-        <emphasis>Annotations regarding
-        <literal>latin1</literal>:</emphasis> MySQL's
-        <literal>latin1</literal> is the same as the Windows
-        <literal>cp1252</literal> character set. This means it is the
-        same as the official <literal>ISO 8859-1</literal> or IANA
-        (Internet Assigned Numbers Authority) <literal>latin1</literal>,
-        but IANA <literal>latin1</literal> treats the code points
-        between 0x80 and 0x9f as <quote>undefined,</quote> while
-        <literal>cp1252</literal>, and therefore MySQL's
-        <literal>latin1</literal>, assign characters for those
-        positions. For example, 0x80 is the Euro sign. For the
-        <quote>undefined</quote> entries in <literal>cp1252</literal>,
-        MySQL translates <literal>0x81</literal> to Unicode
-        <literal>0x0081</literal>, <literal>0x8d</literal> to
-        <literal>0x008d</literal>, <literal>0x8f</literal> to
-        <literal>0x008f</literal>, <literal>0x90</literal> to
-        <literal>0x0090</literal>, and <literal>0x9d</literal> to
-        <literal>0x009d</literal>.
-      </para>
-
     </section>
 
     <section id="charset-ce-sets">
@@ -3585,9 +3586,9 @@
       <title>&title-charset-ce-sets;</title>
 
       <para>
-        We also provide some support for character sets used in the
-        Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
-        and Poland.
+        MySQL provides some support for character sets used in the Czech
+        Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+        Poland.
       </para>
 
       <itemizedlist>
@@ -3746,7 +3747,7 @@
       <para>
         South European and Middle Eastern character sets supported by
         MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
-        Turkish:
+        Turkish.
       </para>
 
       <itemizedlist>
@@ -3893,8 +3894,7 @@
 
       <para>
         The Baltic character sets cover Estonian, Latvian, and
-        Lithuanian languages. There are two Baltic character sets
-        currently supported:
+        Lithuanian languages.
       </para>
 
       <itemizedlist>
@@ -3970,7 +3970,7 @@
       <title>&title-charset-cyrillic-sets;</title>
 
       <para>
-        Here are the Cyrillic character sets and collations for use with
+        The Cyrillic character sets and collations are for use with
         Belarusian, Bulgarian, Russian, and Ukrainian languages.
       </para>
 
@@ -4101,7 +4101,9 @@
         The Asian character sets that we support include Chinese,
         Japanese, Korean, and Thai. These can be complicated. For
         example, the Chinese sets must allow for thousands of different
-        characters.
+        characters. See <xref linkend="charset-cp932"/>, for additional
+        information about the <literal>cp932</literal> and
+        <literal>sjis</literal> character sets.
       </para>
 
       <itemizedlist>
@@ -4425,11 +4427,10 @@
             <para>
               Some <literal>cp932</literal> characters have two
               different code points, both of which convert to the same
-              Unicode code point. So, when converting from Unicode back
-              to <literal>cp932</literal>, one of the code points must
-              be selected. For this <quote>round trip
-              conversion,</quote> the rule recommended by Microsoft is
-              used. (See
+              Unicode code point. When converting from Unicode back to
+              <literal>cp932</literal>, one of the code points must be
+              selected. For this <quote>round trip conversion,</quote>
+              the rule recommended by Microsoft is used. (See
               <ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
             </para>
 
@@ -4465,11 +4466,11 @@
             </itemizedlist>
 
             <para>
-              Information about the Unicode values of
-              <literal>cp932</literal> characters is given in the table
-              shown at
-              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
-              For <literal>cp932</literal> table entries with characters
+              The table shown at
+              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+              provides information about the Unicode values of
+              <literal>cp932</literal> characters. For
+              <literal>cp932</literal> table entries with characters
               under which a four-digit number appears, the number
               represents the corresponding Unicode
               (<literal>ucs2</literal>) encoding. For table entries with

Modified: trunk/refman-5.0/charset.xml
===================================================================
--- trunk/refman-5.0/charset.xml	2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-5.0/charset.xml	2006-01-15 04:58:07 UTC (rev 837)
@@ -2685,8 +2685,7 @@
       </itemizedlist>
 
       <para>
-        <emphasis role="bold">Note</emphasis>: The
-        <literal>ucs2_esperanto_ci</literal> and
+        The <literal>ucs2_esperanto_ci</literal> and
         <literal>utf8_esperanto_ci</literal> collations were added in
         MySQL 5.0.13. The <literal>ucs2_hungarian_ci</literal> and
         <literal>utf8_hungarian_ci</literal> collations were added in
@@ -2698,14 +2697,15 @@
       </indexterm>
 
       <para>
-        The <literal>utf8_unicode_ci</literal> collation is implemented
-        according to the Unicode Collation Algorithm (UCA) described at
+        MySQL implements the <literal>utf8_unicode_ci</literal>
+        collation according to the Unicode Collation Algorithm (UCA)
+        described at
         <ulink url="http://www.unicode.org/reports/tr10/"/>. The
         collation uses the version-4.0.0 UCA weight keys:
         <ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
-        (The following discussion uses
+        The following discussion uses
         <literal>utf8_unicode_ci</literal>, but it is also true for
-        <literal>ucs2_unicode_ci</literal>.)
+        <literal>ucs2_unicode_ci</literal>.
       </para>
 
       <para>
@@ -2732,7 +2732,7 @@
         comparisons between characters. This means that comparisons for
         the <literal>utf8_general_ci</literal> collation are faster, but
         slightly less correct, than comparisons for
-        <literal>utf8_unicode_ci</literal>).
+        <literal>utf8_unicode_ci</literal>.
       </para>
 
       <para>
@@ -2765,8 +2765,8 @@
 </programlisting>
 
       <para>
-        Language-specific collations for the <literal>utf8</literal>
-        character set are implemented only if the ordering with
+        MySQL implements language-specific collations for the
+        <literal>utf8</literal> character set only if the ordering with
         <literal>utf8_unicode_ci</literal> does not work well for a
         language. For example, <literal>utf8_unicode_ci</literal> works
         fine for German and French, so there is no need to create
@@ -2775,7 +2775,7 @@
       </para>
 
       <para>
-        <literal>utf8_general_ci</literal> is also satisfactory for both
+        <literal>utf8_general_ci</literal> also is satisfactory for both
         German and French, except that
         &lsquo;<literal>ß</literal>&rsquo; is equal to
         &lsquo;<literal>s</literal>&rsquo;, and not to
@@ -2918,8 +2918,7 @@
 
         <listitem>
           <para>
-            <literal>latin1</literal> (cp1252 West European) collations
-            (see the annotations about <quote>latin1</quote> below):
+            <literal>latin1</literal> (cp1252 West European) collations:
           </para>
 
           <itemizedlist>
@@ -2975,8 +2974,30 @@
           </itemizedlist>
 
           <para>
-            <literal>latin1</literal> is the default character set. The
-            <literal>latin1_swedish_ci</literal> collation is the
+            <literal>latin1</literal> is the default character set.
+            MySQL's <literal>latin1</literal> is the same as the Windows
+            <literal>cp1252</literal> character set. This means it is
+            the same as the official <literal>ISO 8859-1</literal> or
+            IANA (Internet Assigned Numbers Authority)
+            <literal>latin1</literal>, but IANA
+            <literal>latin1</literal> treats the code points between
+            <literal>0x80</literal> and <literal>0x9f</literal> as
+            <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+            and therefore MySQL's <literal>latin1</literal>, assign
+            characters for those positions. For example,
+            <literal>0x80</literal> is the Euro sign. For the
+            <quote>undefined</quote> entries in
+            <literal>cp1252</literal>, MySQL translates
+            <literal>0x81</literal> to Unicode
+            <literal>0x0081</literal>, <literal>0x8d</literal> to
+            <literal>0x008d</literal>, <literal>0x8f</literal> to
+            <literal>0x008f</literal>, <literal>0x90</literal> to
+            <literal>0x0090</literal>, and <literal>0x9d</literal> to
+            <literal>0x009d</literal>.
+          </para>
+
+          <para>
+            The <literal>latin1_swedish_ci</literal> collation is the
             default that probably is used by the majority of MySQL
             customers. Although it is frequently said that it is based
             on the Swedish/Finnish collation rules, there are Swedes and
@@ -3077,27 +3098,6 @@
 
       </itemizedlist>
 
-      <para>
-        <emphasis>Annotations regarding
-        <literal>latin1</literal>:</emphasis> MySQL's
-        <literal>latin1</literal> is the same as the Windows
-        <literal>cp1252</literal> character set. This means it is the
-        same as the official <literal>ISO 8859-1</literal> or IANA
-        (Internet Assigned Numbers Authority) <literal>latin1</literal>,
-        but IANA <literal>latin1</literal> treats the code points
-        between 0x80 and 0x9f as <quote>undefined,</quote> while
-        <literal>cp1252</literal>, and therefore MySQL's
-        <literal>latin1</literal>, assign characters for those
-        positions. For example, 0x80 is the Euro sign. For the
-        <quote>undefined</quote> entries in <literal>cp1252</literal>,
-        MySQL translates <literal>0x81</literal> to Unicode
-        <literal>0x0081</literal>, <literal>0x8d</literal> to
-        <literal>0x008d</literal>, <literal>0x8f</literal> to
-        <literal>0x008f</literal>, <literal>0x90</literal> to
-        <literal>0x0090</literal>, and <literal>0x9d</literal> to
-        <literal>0x009d</literal>.
-      </para>
-
     </section>
 
     <section id="charset-ce-sets">
@@ -3105,9 +3105,9 @@
       <title>&title-charset-ce-sets;</title>
 
       <para>
-        We also provide some support for character sets used in the
-        Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
-        and Poland.
+        MySQL provides some support for character sets used in the Czech
+        Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+        Poland.
       </para>
 
       <itemizedlist>
@@ -3266,7 +3266,7 @@
       <para>
         South European and Middle Eastern character sets supported by
         MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
-        Turkish:
+        Turkish.
       </para>
 
       <itemizedlist>
@@ -3413,8 +3413,7 @@
 
       <para>
         The Baltic character sets cover Estonian, Latvian, and
-        Lithuanian languages. There are two Baltic character sets
-        currently supported:
+        Lithuanian languages.
       </para>
 
       <itemizedlist>
@@ -3490,7 +3489,7 @@
       <title>&title-charset-cyrillic-sets;</title>
 
       <para>
-        Here are the Cyrillic character sets and collations for use with
+        The Cyrillic character sets and collations are for use with
         Belarusian, Bulgarian, Russian, and Ukrainian languages.
       </para>
 
@@ -3621,7 +3620,9 @@
         The Asian character sets that we support include Chinese,
         Japanese, Korean, and Thai. These can be complicated. For
         example, the Chinese sets must allow for thousands of different
-        characters.
+        characters. See <xref linkend="charset-cp932"/>, for additional
+        information about the <literal>cp932</literal> and
+        <literal>sjis</literal> character sets.
       </para>
 
       <itemizedlist>
@@ -3942,11 +3943,10 @@
             <para>
               Some <literal>cp932</literal> characters have two
               different code points, both of which convert to the same
-              Unicode code point. So, when converting from Unicode back
-              to <literal>cp932</literal>, one of the code points must
-              be selected. For this <quote>round trip
-              conversion,</quote> the rule recommended by Microsoft is
-              used. (See
+              Unicode code point. When converting from Unicode back to
+              <literal>cp932</literal>, one of the code points must be
+              selected. For this <quote>round trip conversion,</quote>
+              the rule recommended by Microsoft is used. (See
               <ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
             </para>
 
@@ -3982,11 +3982,11 @@
             </itemizedlist>
 
             <para>
-              Information about the Unicode values of
-              <literal>cp932</literal> characters is given in the table
-              shown at
-              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
-              For <literal>cp932</literal> table entries with characters
+              The table shown at
+              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+              provides information about the Unicode values of
+              <literal>cp932</literal> characters. For
+              <literal>cp932</literal> table entries with characters
               under which a four-digit number appears, the number
               represents the corresponding Unicode
               (<literal>ucs2</literal>) encoding. For table entries with

Modified: trunk/refman-5.1/charset.xml
===================================================================
--- trunk/refman-5.1/charset.xml	2006-01-15 04:57:51 UTC (rev 836)
+++ trunk/refman-5.1/charset.xml	2006-01-15 04:58:07 UTC (rev 837)
@@ -2677,8 +2677,7 @@
       </itemizedlist>
 
       <para>
-        <emphasis role="bold">Note</emphasis>: The
-        <literal>ucs2_hungarian_ci</literal> and
+        The <literal>ucs2_hungarian_ci</literal> and
         <literal>utf8_hungarian_ci</literal> collations were added in
         MySQL 5.1.5.
       </para>
@@ -2688,14 +2687,15 @@
       </indexterm>
 
       <para>
-        The <literal>utf8_unicode_ci</literal> collation is implemented
-        according to the Unicode Collation Algorithm (UCA) described at
+        MySQL implements the <literal>utf8_unicode_ci</literal>
+        collation according to the Unicode Collation Algorithm (UCA)
+        described at
         <ulink url="http://www.unicode.org/reports/tr10/"/>. The
         collation uses the version-4.0.0 UCA weight keys:
         <ulink url="http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt"/>.
-        (The following discussion uses
+        The following discussion uses
         <literal>utf8_unicode_ci</literal>, but it is also true for
-        <literal>ucs2_unicode_ci</literal>.)
+        <literal>ucs2_unicode_ci</literal>.
       </para>
 
       <para>
@@ -2722,7 +2722,7 @@
         comparisons between characters. This means that comparisons for
         the <literal>utf8_general_ci</literal> collation are faster, but
         slightly less correct, than comparisons for
-        <literal>utf8_unicode_ci</literal>).
+        <literal>utf8_unicode_ci</literal>.
       </para>
 
       <para>
@@ -2755,8 +2755,8 @@
 </programlisting>
 
       <para>
-        Language-specific collations for the <literal>utf8</literal>
-        character set are implemented only if the ordering with
+        MySQL implements language-specific collations for the
+        <literal>utf8</literal> character set only if the ordering with
         <literal>utf8_unicode_ci</literal> does not work well for a
         language. For example, <literal>utf8_unicode_ci</literal> works
         fine for German and French, so there is no need to create
@@ -2765,7 +2765,7 @@
       </para>
 
       <para>
-        <literal>utf8_general_ci</literal> is also satisfactory for both
+        <literal>utf8_general_ci</literal> also is satisfactory for both
         German and French, except that
         &lsquo;<literal>ß</literal>&rsquo; is equal to
         &lsquo;<literal>s</literal>&rsquo;, and not to
@@ -2908,8 +2908,7 @@
 
         <listitem>
           <para>
-            <literal>latin1</literal> (cp1252 West European) collations
-            (see the annotations about <quote>latin1</quote> below):
+            <literal>latin1</literal> (cp1252 West European) collations:
           </para>
 
           <itemizedlist>
@@ -2965,8 +2964,30 @@
           </itemizedlist>
 
           <para>
-            <literal>latin1</literal> is the default character set. The
-            <literal>latin1_swedish_ci</literal> collation is the
+            <literal>latin1</literal> is the default character set.
+            MySQL's <literal>latin1</literal> is the same as the Windows
+            <literal>cp1252</literal> character set. This means it is
+            the same as the official <literal>ISO 8859-1</literal> or
+            IANA (Internet Assigned Numbers Authority)
+            <literal>latin1</literal>, but IANA
+            <literal>latin1</literal> treats the code points between
+            <literal>0x80</literal> and <literal>0x9f</literal> as
+            <quote>undefined,</quote> whereas <literal>cp1252</literal>,
+            and therefore MySQL's <literal>latin1</literal>, assign
+            characters for those positions. For example,
+            <literal>0x80</literal> is the Euro sign. For the
+            <quote>undefined</quote> entries in
+            <literal>cp1252</literal>, MySQL translates
+            <literal>0x81</literal> to Unicode
+            <literal>0x0081</literal>, <literal>0x8d</literal> to
+            <literal>0x008d</literal>, <literal>0x8f</literal> to
+            <literal>0x008f</literal>, <literal>0x90</literal> to
+            <literal>0x0090</literal>, and <literal>0x9d</literal> to
+            <literal>0x009d</literal>.
+          </para>
+
+          <para>
+            The <literal>latin1_swedish_ci</literal> collation is the
             default that probably is used by the majority of MySQL
             customers. Although it is frequently said that it is based
             on the Swedish/Finnish collation rules, there are Swedes and
@@ -3067,27 +3088,6 @@
 
       </itemizedlist>
 
-      <para>
-        <emphasis>Annotations regarding
-        <literal>latin1</literal>:</emphasis> MySQL's
-        <literal>latin1</literal> is the same as the Windows
-        <literal>cp1252</literal> character set. This means it is the
-        same as the official <literal>ISO 8859-1</literal> or IANA
-        (Internet Assigned Numbers Authority) <literal>latin1</literal>,
-        but IANA <literal>latin1</literal> treats the code points
-        between 0x80 and 0x9f as <quote>undefined,</quote> while
-        <literal>cp1252</literal>, and therefore MySQL's
-        <literal>latin1</literal>, assign characters for those
-        positions. For example, 0x80 is the Euro sign. For the
-        <quote>undefined</quote> entries in <literal>cp1252</literal>,
-        MySQL translates <literal>0x81</literal> to Unicode
-        <literal>0x0081</literal>, <literal>0x8d</literal> to
-        <literal>0x008d</literal>, <literal>0x8f</literal> to
-        <literal>0x008f</literal>, <literal>0x90</literal> to
-        <literal>0x0090</literal>, and <literal>0x9d</literal> to
-        <literal>0x009d</literal>.
-      </para>
-
     </section>
 
     <section id="charset-ce-sets">
@@ -3095,9 +3095,9 @@
       <title>&title-charset-ce-sets;</title>
 
       <para>
-        We also provide some support for character sets used in the
-        Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia,
-        and Poland.
+        MySQL provides some support for character sets used in the Czech
+        Republic, Slovakia, Hungary, Romania, Slovenia, Croatia, and
+        Poland.
       </para>
 
       <itemizedlist>
@@ -3262,7 +3262,7 @@
       <para>
         South European and Middle Eastern character sets supported by
         MySQL include Armenian, Arabic, Georgian, Greek, Hebrew, and
-        Turkish:
+        Turkish.
       </para>
 
       <itemizedlist>
@@ -3409,8 +3409,7 @@
 
       <para>
         The Baltic character sets cover Estonian, Latvian, and
-        Lithuanian languages. There are two Baltic character sets
-        currently supported:
+        Lithuanian languages.
       </para>
 
       <itemizedlist>
@@ -3486,7 +3485,7 @@
       <title>&title-charset-cyrillic-sets;</title>
 
       <para>
-        Here are the Cyrillic character sets and collations for use with
+        The Cyrillic character sets and collations are for use with
         Belarusian, Bulgarian, Russian, and Ukrainian languages.
       </para>
 
@@ -3617,7 +3616,9 @@
         The Asian character sets that we support include Chinese,
         Japanese, Korean, and Thai. These can be complicated. For
         example, the Chinese sets must allow for thousands of different
-        characters.
+        characters. See <xref linkend="charset-cp932"/>, for additional
+        information about the <literal>cp932</literal> and
+        <literal>sjis</literal> character sets.
       </para>
 
       <itemizedlist>
@@ -3938,11 +3939,10 @@
             <para>
               Some <literal>cp932</literal> characters have two
               different code points, both of which convert to the same
-              Unicode code point. So, when converting from Unicode back
-              to <literal>cp932</literal>, one of the code points must
-              be selected. For this <quote>round trip
-              conversion,</quote> the rule recommended by Microsoft is
-              used. (See
+              Unicode code point. When converting from Unicode back to
+              <literal>cp932</literal>, one of the code points must be
+              selected. For this <quote>round trip conversion,</quote>
+              the rule recommended by Microsoft is used. (See
               <ulink url="http://support.microsoft.com/kb/170559/EN-US/"/>.)
             </para>
 
@@ -3978,11 +3978,11 @@
             </itemizedlist>
 
             <para>
-              Information about the Unicode values of
-              <literal>cp932</literal> characters is given in the table
-              shown at
-              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>.
-              For <literal>cp932</literal> table entries with characters
+              The table shown at
+              <ulink url="http://www.microsoft.com/globaldev/reference/dbcs/932.htm"/>
+              provides information about the Unicode values of
+              <literal>cp932</literal> characters. For
+              <literal>cp932</literal> table entries with characters
               under which a four-digit number appears, the number
               represents the corresponding Unicode
               (<literal>ucs2</literal>) encoding. For table entries with

Thread
svn commit - mysqldoc@docsrva: r837 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul15 Jan