| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
