diff options
| author | Sebastian Rasmussen <sebras@gmail.com> | 2018-09-14 00:46:28 +0800 |
|---|---|---|
| committer | Robin Watts <robin.watts@artifex.com> | 2018-09-19 17:13:45 +0100 |
| commit | 2b06a50140b7eb81eb55dcc1547fee4e8842e697 (patch) | |
| tree | 63b760b18c429a1b916c97f6a9994dc657bda400 /source/helpers/mu-threads/mu-threads.c | |
| parent | 687a3b20407e1489d63194137d14cf61d2b72721 (diff) | |
| download | mupdf-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/helpers/mu-threads/mu-threads.c')
0 files changed, 0 insertions, 0 deletions