pardes.git/mupdf.zig, branch release-0.24

A PDF with a JPEG image no longer crashes ReleaseSafe and Debug builds: libjpeg and jbig2dec are built without UBSan, as the rest of MuPDF is

2026-10-01T16:04:28Z

libjpeg calls filter-dct.c's source manager through a function pointer; with -fsanitize=function on the caller and no type hash on the uninstrumented callee, the call trapped (Illegal instruction in jpeg_fill_bit_buffer). The Intel SDM vol. 2 crashed pardes on its first page. Co-Authored-By: Claude Opus 5.5

Inflate MuPDF's streams with the zlib FreeType links

2026-10-01T03:12:14Z

MuPDF compiled its bundled zlib 1.3.1 (ZLIB_SRC) into libmupdf.a, and the freetype package links the zlib package, 1.3.2, for its gzip module: 68 symbols defined twice, with the linker keeping one of each. MuPDF now links that same zlib artifact and stops compiling its own. build.zig asks FreeType's build for zlib with the options FreeType asks with, which the build's dependency cache answers with the very artifact FreeType links, so the tty and the gui each carry exactly one zlib. MuPDF hands zlib its own allocation functions on every stream, so nothing about where the memory comes from changes. Every page of the three PDFs in docs/ still renders bit for bit as before, at 144 and at 300 dpi. Co-Authored-By: Claude Opus 5.5 (1M context)

Build MuPDF against the FreeType the gui links, not the slim one it bundles

2026-10-01T03:12:14Z

MuPDF compiled its own FreeType 2.13.3 (FREETYPE_SRC, trimmed by scripts/freetype's slimftmodules.h and slimftoptions.h) into libmupdf.a, and the gui also links the freetype package, 2.14.3 in its full configuration. The two define the same 312 symbols, and a linker handed both keeps one of each: the gui's MuPDF ran the package's FreeType compiled against the slim headers, while the tty ran the slim one. Now there is one. mupdf.zig takes the build's freetype artifact, links it (its headers come with it) and no longer compiles FREETYPE_SRC or puts the slim headers on the include path. The shared artifact is built at c_optimize, as MuPDF is, so a Debug gui's glyph atlas now uses a ReleaseFast FreeType too; one artifact cannot be both. The tty gains the full FreeType's extra modules, which FT_Add_Default_Modules registers whether or not a PDF needs them. MuPDF asks nothing of FreeType the full configuration lacks: every page of docs/design.pdf, docs/9p.pdf and docs/registry.pdf renders bit for bit as before, at 144 and at 300 dpi. Co-Authored-By: Claude Opus 5.5 (1M context)

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

2026-08-11T14:35:08Z

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.

replace ArrayLists with bounded storage

2026-08-10T12:17:07Z

tty/image: big harness + golden coverage pass

2026-08-10T12:17:07Z