mupdf: -Djpx, on by default, so a scanned PDF is not a blank page

A scan is typically one /JPXDecode image per page. With FZ_ENABLE_JPX=0 and no
openjpeg compiled, MuPDF raised "JPX support disabled" for every one of them
and handed back a page with nothing drawn on it -- the pane opened, the page
count was right, and the page was empty, which reads as a renderer bug rather
than a missing codec.

OPENJPEG_SRC comes out of Makelists through the same makeSources path the other
three third-party libraries already use, with MuPDF's own OPENJPEG_CFLAGS and
OPENJPEG_BUILD_CFLAGS, so there is no second source list to go stale.
-fno-sanitize=undefined for the reason source/fitz needs it: upstream C full of
deliberate wrapping arithmetic that ReleaseSafe's trap-mode UBSan would turn
into a crash.

FZ_ENABLE_JPX reaches the public headers, so Result carries the flag and
linkTo hands consumers the archive's actual value instead of re-deriving it --
a consumer that disagrees is an ODR bug that shows up as a wrong struct layout
at runtime rather than as a link error.

A switch at all because it is 31 files of third-party C parsing untrusted
input, and openjpeg has the CVE history to match. Default on because a viewer
that cannot open scans is the more surprising default. +1.6 MB of archive;
mupdf-check passes with it on and off.

0 files changed, 0 insertions, 0 deletions