Add a supported host-font configuration for bundled LibreOffice and Poppler runtimes

What is the type of issue?

Feature request / bug

What is the issue?

The bundled primary runtime on macOS does not provide a supported way to expose the host system font directories to bundled fontconfig-based tools such as LibreOffice and Poppler.

In a macOS Codex Desktop runtime, the bundled LibreOffice can convert a PPTX to PDF, but Simplified Chinese text may disappear when soffice is launched without an explicit FONTCONFIG_FILE environment variable.

The runtime contains its own Fontconfig configuration and fonts, but the bundled Fontconfig library is compiled with an internal install-time path similar to:

/@.__________________________________________________OOO/etc/fonts

The runtime sandbox does not expose a normal /etc/fonts directory, and LibreOffice does not automatically load the configuration shipped under its application resources:

LibreOfficeDev.app/Contents/Resources/fontconfig/fonts.conf

As a result, editing that bundled fonts.conf alone is insufficient for a bare soffice invocation.

Reproduction

Environment:

OS: macOS arm64
Codex Desktop primary runtime bundle: 26.709.11516
LibreOfficeDev: 26.8.0.0.alpha0

The runtime provides a bundled soffice and Poppler. With the host system font directories not explicitly configured:

unset FONTCONFIG_FILE FONTCONFIG_PATH
soffice --headless --convert-to pdf input.pptx --outdir /tmp/output

Fontconfig emits warnings such as:

Fontconfig warning: no <cachedir> elements found
Fontconfig warning: adding <cachedir>/@.__________________________________________________OOO/var/cache/fontconfig

A PPTX containing Simplified Chinese text converts to PDF, but the Chinese glyphs are missing or blank. pdffonts shows only the bundled Latin fonts, for example LinuxLibertineG.

By contrast, explicitly pointing Fontconfig at a configuration that includes the host directories makes the same conversion work:

export FONTCONFIG_FILE=/path/to/runtime/config/fontconfig/fonts.conf
export FONTCONFIG_PATH=/path/to/runtime/config/fontconfig
soffice --headless --convert-to pdf input.pptx --outdir /tmp/output

The working configuration references:

/System/Library/Fonts
/System/Library/Assets
/System/Library/AssetsV2
/Library/Fonts
~/Library/Fonts

The resulting PDF embeds PingFangSC-Regular, and the rendered Chinese text is visible.

Expected behavior

The primary runtime should provide a supported runtime-level font configuration mechanism so all bundled renderers can read host fonts without per-command workarounds.

Possible designs:

• A runtime configuration option for read-only host font directories.
• A documented FONTCONFIG_FILE / FONTCONFIG_PATH environment hook applied to all runtime child processes.
• A runtime launcher that mounts or exposes host font directories read-only and points Fontconfig at a runtime-owned configuration.
• A documented setting for selecting a curated system font root without copying fonts into the runtime.

The configuration should cover at least:

• LibreOffice / soffice
• Poppler tools such as pdftoppm and pdftocairo
• Other bundled renderers that use Fontconfig

Why this matters

Users should not need to:

• Copy PingFang or other system fonts into the runtime.
• Modify cached runtime files after every Codex upgrade.
• Create command-specific wrappers.
• Guess or patch the internal /@.../etc/fonts install path.
• Accept missing CJK text in generated PDFs.

A read-only host font directory exposure would avoid duplicated font files and would be low risk compared with exposing broader host filesystem paths.

Related issue

This is related to #28889, which discusses Fontconfig cache handling for Poppler in sandboxed workspaces, but this report is specifically about the missing supported host-font configuration and the resulting CJK rendering failure in bundled LibreOffice/Poppler.

Additional information

A local workaround is to set FONTCONFIG_FILE and FONTCONFIG_PATH in the runtime launch environment and use a configuration that points to the macOS system font directories. This works, but the runtime currently has no documented global hook for doing so, and modifying files under ~/.cache/codex-runtimes is vulnerable to runtime replacement during upgrades.