summaryrefslogtreecommitdiff
path: root/source/pdf/pdf-xref.c
diff options
context:
space:
mode:
authorSebastian Rasmussen <sebras@gmail.com>2018-09-14 00:46:28 +0800
committerRobin Watts <robin.watts@artifex.com>2018-09-19 17:13:45 +0100
commit2b06a50140b7eb81eb55dcc1547fee4e8842e697 (patch)
tree63b760b18c429a1b916c97f6a9994dc657bda400 /source/pdf/pdf-xref.c
parent687a3b20407e1489d63194137d14cf61d2b72721 (diff)
downloadmupdf-2b06a50140b7eb81eb55dcc1547fee4e8842e697.tar.xz
Update to OpenJPEG 2.3.0.
There is a regression for 2325_-_JPX_image_with_padding_rejected.pdf. Object 3 in that document is a JPX-encoded image. Its EOC marker is preceded by two extra bytes of data, 0x80 0x80. This makes the file broken according to the JPEG 2000 specification. Acrobat Reader and the Kakadu JPX decoder accepts this file without issues, so OpenJPEG 2.1.0 added code to fix this (bug 226, commit 005e75bdc). That fix detects exactly two bytes of 0x80 0x80, a rather brittle fix. Adding more padding or changing the padding byte values is not accepted. Adding more padding is acceptable to Acrobat Reader and Kakadu. An unrelated fix for another problem has since broken OpenJPEG's support for this broken image.
Diffstat (limited to 'source/pdf/pdf-xref.c')
0 files changed, 0 insertions, 0 deletions