Handle odd PDFDoc codepoints in UTF-8 during transcoding (fixes #650)

There are codepoints in PDFDoc that are not valid UTF-8 but map to
valid UTF-8. We were handling those correctly with bidirectional
mapping.

However, if those same code points appeared in UTF-8, where they have
no meaning, they were left as fixed points when converting to PDFDoc,
where they do have meaning. This change recognizes them as errors.

1 files changed, 6 insertions, 0 deletions

diff --git a/ChangeLog b/ChangeLog
index f6879a4d..b63a785d 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2022-02-15  Jay Berkenbilt  <ejb@ql.org>
+
+	* Don't map 0x18 through 0x1f, 0x7f, 0x9f, or 0xad as fixed points
+	when transcoding UTF-8 to PDFDoc. These codepoints have different
+	meanings in those two encoding systems. Fixes #650.
+
 2022-02-11  Jay Berkenbilt  <ejb@ql.org>
 
 	* 10.6.1: release