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

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) <[email protected]>

0 files changed, 0 insertions, 0 deletions