From 42d396f1dd8d38294e45b14021cd72c13850a53b Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Sun, 18 Aug 2019 21:26:19 -0400 Subject: Handle invalid name tokens symmetrically for PDF < 1.2 (fixes #332) --- ChangeLog | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'ChangeLog') diff --git a/ChangeLog b/ChangeLog index 51fb9aa9..0f53db35 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,30 @@ +2019-08-19 Jay Berkenbilt + + * Properly handle name tokens containing # not preceding two + hexadecimal digits. Such names are invalid in PDF >= 1.2 but valid + in PDF 1.0 and 1.1. Prior to this fix, qpdf's behavior was to + treat such tokens as an error for PDF >= 1.2, but for older PDF + tokens, the name was silently accepted, and when the name token + was written out, the # was changed to #23, which is the correct + way to represent a # character. This behavior was problematic for + several reasons: one is that, ordinarily, content streams are not + parsed, so this would cause things like image references whose + names contained # to break. Also, even if the input file was 1.0 + or 1.1, there's no guarantee that the output file wouldn't be + written at a new version, resulting in invalid name tokens. The + new behavior is to issue a warning upon encountering such a token + but to accept it, regardless of the PDF version. Such tokens are + written out properly as well. Additionally, the warning message + indicates that the tokens are invalid for PDF >= 1.2. Fixes #332. + + * Non-compatible API change: remove + QPDFTokenizer::allowPoundAnywhereInName(). There were a lot of + problems with this. When it was used, any name tokens read would + always be modified on output, which is never the correct behavior. + This method used to signal QPDFTokenizer to not treat # specially + in name tokens, which resulted in the incorrect behavior whose fix + is described in the preceding item. + 2019-08-18 Jay Berkenbilt * When traversing the pages tree, if an invalid /Type key is -- cgit v1.2.3-70-g09d2