mirror of
https://github.com/SerenityOS/serenity
synced 2024-07-21 18:15:58 +00:00
9495f64f91
A local (non-public) PDF I have lying around contains this in a page's operator stream: ``` [<00b4003e> 3 <002600480051> 3 <005700550044004f0003> -29 <00330044> 3 <0055> -3 <004e0040> 4 <0003> -29 <004c00560003> -31 <0057004b> 4 <00480003> -37 <0050 >] TJ ``` That is, there's a newline in a hexstring after a character. This led to `Parser error at offset 5184: Unexpected character`. The spec says in 3.2.3 String Objects, Hexadecimal Strings: """Each pair of hexadecimal digits defines one byte of the string. White-space characters (such as space, tab, carriage return, line feed, and form feed) are ignored.""" But we didn't ignore whitespace before or after a character, only in between the bytes. The spec also says: """If the final digit of a hexadecimal string is missing—that is, if there is an odd number of digits—the final digit is assumed to be 0.""" In that case, we were skipping the closing `>` twice -- or, more accurately, we ignored the character after it too. This has been wrong all the way back in #6974. Add a test that fails if either of the two changes isn't present. |
||
|---|---|---|
| .. | ||
| CMakeLists.txt | ||
| colorspaces.pdf | ||
| complex.pdf | ||
| encoding.pdf | ||
| encryption_nocopy.pdf | ||
| linearized.pdf | ||
| non-linearized.pdf | ||
| oss-fuzz-testcase-62065.pdf | ||
| password-is-sup.pdf | ||
| pattern.pdf | ||
| TestPDF.cpp | ||
| text.pdf | ||
| type1.pdf | ||
| type3.pdf | ||