Simple SAX parser library with added UTF-16 support. When we build expat internally ("bundled"), we build two variants: One that has an "ASCII" (actually UTF-8) API, another that has a "Unicode" (meaning UTF-16) API. Additionally, expat is split into two parts, expat_xmlparse and expat_xmltok. It's the former which has the two variants, ascii_expat_xmlparse (UTF-8) and expat_xmlparse (UTF-16). Code that uses expat then declares in its .mk file which one it wants to use. See the magic in ../RepositoryExternal.mk, where in the expat_utf16 case -DXML_UNICODE is passed when compiling source code that wants to use the UTF-16 variant. Now, this sounds fairly clear so far. But wait. LO can also be conigured to use a *system* expat library. The System expat library is only available as one variant, the "ASCII" one. (But the library is still called just "libexpat", no "ascii" in the name, that is just LO/OO's convention.) So how does this work then, how can the code that wants to use the UTF-16 expat API then actually use the "ASCII" (UTF-8) expat API? Well, in the SYSTEM_EXPAT case no -DXML_UNICODE is used, so the code needs to check that and adapt. So in the system libexpat case, mentioning expat_utf16 in a .mk file doesn't mean any UTF-16-using libexpat would actually be used. Yeah, this is silly, confusing, etc. Furthermore, at least Debian actually *does* have also a "Unicode" expat library, called libexpatw. Debian's LO does not use that, though. (Using it would require modifications to the LO build machinery.) Now, if LO manages just fine with just the UTF-8 (or, "ASCII") system libexpat in builds where that is used, why is a separate Unicode one needed when an internal expat is used? Good question. Next question. Patches welcome. From: [http://expat.sourceforge.net/]