From 03e27709f32ebc83b1c351da5c03ffb2d18f28da Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Sat, 27 Apr 2019 19:54:52 -0400 Subject: Improve Unicode filename testing Remove dependency on the behavior of perl for reliable creation of Unicode file names on Windows. --- manual/qpdf-manual.xml | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'manual') diff --git a/manual/qpdf-manual.xml b/manual/qpdf-manual.xml index dac5f00d..1df6e788 100644 --- a/manual/qpdf-manual.xml +++ b/manual/qpdf-manual.xml @@ -2612,6 +2612,31 @@ outfile.pdf + + A Note About Unicode File Names + + When strings are passed to qpdf library routines either as + char* or as std::string, + they are treated as byte arrays except where otherwise noted. When + Unicode is desired, qpdf wants UTF-8 unless otherwise noted in + comments in header files. In modern UNIX/Linux environments, this + generally does the right thing. In Windows, it's a bit more + complicated. Starting in qpdf 8.4.0, passwords that contain + Unicode characters are handled much better, and starting in qpdf + 8.4.1, the library attempts to properly handle Unicode characters + in filenames. In particular, in Windows, if a UTF-8 encoded string + is used as a filename in either QPDF or + QPDFWriter, it is internally converted to + wchar_t*, and Unicode-aware Windows APIs are + used. As such, qpdf will generally operate properly on files with + non-ASCII characters in their names as long as the filenames are + UTF-8 encoded for passing into the qpdf library API, but there are + still some rough edges, such as the encoding of the filenames in + error messages our CLI output messages. Patches or bug reports are + welcome for any continuing issues with Unicode file names in + Windows. + + QPDF JSON -- cgit v1.2.3-54-g00ecf