Win32 apply: Fixes, comments

[wimlib] / doc / imagex.1.in

diff --git a/doc/imagex.1.in b/doc/imagex.1.in
index 6838f2a170ced16fbddeea1957a62ceaed4a91e9..21ebba0cb14ae1cb11caa5c21188a311e4b45334 100644 (file)
--- a/doc/imagex.1.in
+++ b/doc/imagex.1.in
@@ -1,4 +1,4 @@
-.TH IMAGEX 1 "March 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
+.TH IMAGEX 1 "April 2013" "@IMAGEX_PROGNAME@ @VERSION@" "User Commands"
 .SH NAME
 @IMAGEX_PROGNAME@ \- Create, modify, extract, mount, or unmount a WIM (Windows Imaging Format) archive
 .SH SYNOPSIS
@@ -151,18 +151,11 @@ UNIX builds.)
 
 .SH LOCALES AND CHARACTER ENCODINGS
 
-wimlib 1.3.0 has improved support for alternate character encodings.
-However, not everything has been well tested, and on UNIX you are strongly
-encouraged to use a UTF-8 locale so that you do not run into any problems.
-In particular, if your locale uses a character encoding that is
-not UTF-8, then you will not be able to open or capture WIM files containing
-files with paths not representable in the current locale's character encoding.
-
-Similar restrictions apply to the Windows-native build of wimlib, but
-unfortunately Windows does not support UTF-8 locales.  So you will not be able
-to apply a WIM image containing files with names not representable in the
-current Windows code page, nor will you be able to capture a directory tree
-containing files with names not representable in the current Windows code page.
+On Windows, wimlib 1.3.2 and later works in UTF-16LE, and there should be no
+problems with character encodings.
+
+On UNIX, wimlib works primarily in the locale-dependent multibyte encoding,
+which you are strongly recommended to set to UTF-8 to avoid any problems.
 
 .SH WARNING