Library Updates and 'ext' directory cleanup (by Buggler)

- utfcpp 2.3.4
- libpng 1.2.50
- zlib 1.2.8

git-svn-id: https://ja2svn.mooo.com/source/ja2/trunk/GameSource/ja2_v1.13/Build@6312 3b4a5df2-a311-0410-b5c6-a8a6f20db521

ext/VFS/ext/utfcpp/doc/utf8cpp.html

@@ -88,9 +88,6 @@
         <li>
           <a href="#points">Points of Interest</a>
         </li>
-        <li>
-          <a href="#conclusion">Conclusion</a>
-        </li>
         <li>
           <a href="#links">Links</a>
         </li>
@@ -101,10 +98,12 @@
     </h2>
     <p>
       Many C++ developers miss an easy and portable way of handling Unicode encoded
-      strings. The original C++ Standard (known as C++98 or C++03) is Unicode agnostic,
-      and while some work is being done to introduce Unicode to the next incarnation
-      called C++0x, for the moment nothing of the sort is available. In the meantime,
-      developers use third party libraries like ICU, OS specific capabilities, or simply
+      strings. The original C++ Standard (known as C++98 or C++03) is Unicode agnostic.
+      C++11 provides some support for Unicode on core language and library level:
+      u8, u, and U character and string literals, char16_t and char32_t character types,
+      u16string and u32string library classes, and codecvt support for conversions 
+      between Unicode encoding forms.
+      In the meantime, developers use third party libraries like ICU, OS specific capabilities, or simply
       roll out their own solutions.
     </p>
     <p>
@@ -441,7 +440,9 @@ assert (w == twochars);
       This function has two purposes: one is two iterate backwards through a UTF-8
       encoded string. Note that it is usually a better idea to iterate forward instead,
       since <code>utf8::next</code> is faster. The second purpose is to find a beginning
-      of a UTF-8 sequence if we have a random position within a string.
+      of a UTF-8 sequence if we have a random position within a string. Note that in that
+      case <code>utf8::prior</code> may not detect an invalid UTF-8 sequence in some scenarios:
+      for instance if there are superfluous trail octets, it will just skip them.
     </p> 
     <p>
       <code>it</code> will typically point to the beginning of
@@ -451,10 +452,12 @@ assert (w == twochars);
       beginning with that octet is decoded to a 32 bit representation and returned.
     </p>
     <p>
-      In case <code>pass_end</code> is reached before a UTF-8 lead octet is hit, or if an
+      In case <code>start</code> is reached before a UTF-8 lead octet is hit, or if an
       invalid UTF-8 sequence is started by the lead octet, an <code>invalid_utf8</code>
       exception is thrown.
     </p>
+    <p>In case <code>start</code> equals <code>it</code>, a <code>not_enough_room</code>
+      exception is thrown.
     <h4>
       utf8::previous
     </h4>
@@ -512,7 +515,7 @@ assert (w == twochars);
       beginning with that octet is decoded to a 32 bit representation and returned.
     </p>
     <p>
-      In case <code>pass_end</code> is reached before a UTF-8 lead octet is hit, or if an
+      In case <code>pass_start</code> is reached before a UTF-8 lead octet is hit, or if an
       invalid UTF-8 sequence is started by the lead octet, an <code>invalid_utf8</code>
       exception is thrown
     </p>
@@ -988,7 +991,7 @@ assert (bbom == <span class="literal">true</span>);
 <span class="keyword">unsigned char</span> byte_order_mark[] = {<span class=
 "literal">0xef</span>, <span class="literal">0xbb</span>, <span class=
 "literal">0xbf</span>};
-<span class="keyword">bool</span> bbom = is_bom(byte_order_mark, byte_order_mark + <span class="keyword">sizeof</span>(byte_order_mark));
+<span class="keyword">bool</span> bbom = is_bom(byte_order_mark);
 assert (bbom == <span class="literal">true</span>);
 </pre>
     <p>
@@ -1726,7 +1729,7 @@ assert (*un_it == <span class="literal">0x10346</span>);
         for Windows (both 32 and 64 bit), and most 32 bit and 64 bit Unix derivatives.
       </li>
       <li>
-        Lightweight: follow the "pay only for what you use" guidline.
+        Lightweight: follow the "pay only for what you use" guideline.
       </li>
       <li>
         Unintrusive: avoid forcing any particular design or even programming style on the
@@ -1747,6 +1750,10 @@ assert (*un_it == <span class="literal">0x10346</span>);
         non-generic, and doesn't play well with the Standard Library. I definitelly
         recommend looking at ICU even if you don't plan to use it.
       </li>
+      <li>
+        C++11 language and library features. Still far from complete, and not widely
+        supported by compiler vendors. 
+      </li>
       <li>
         <a href=
         "http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch03s04.html">Glib::ustring</a>.
@@ -1757,18 +1764,9 @@ assert (*un_it == <span class="literal">0x10346</span>);
       <li>
         Platform dependent solutions: Windows and POSIX have functions to convert strings
         from one encoding to another. That is only a subset of what my library offers,
-        but if that is all you need it may be good enough, especially given the fact that
-        these functions are mature and tested in production.
+        but if that is all you need it may be good enough.
       </li>
     </ol>
-    <h2 id="conclusion">
-      Conclusion
-    </h2>
-    <p>
-      Until Unicode becomes officially recognized by the C++ Standard Library, we need to
-      use other means to work with UTF-8 strings. Template functions I describe in this
-      article may be a good step in this direction.
-    </p>
     <h2 id="links">
       Links
     </h2>