[RensTillmann]

Summary

Code part of #137 on 6.4. For non-Latin PDF languages the plugin printed super_common_i18n.fonts = {link: ...} as a raw <script> on wp_footer (priority 100). If a JavaScript optimization plugin moves or delays the localized super_common_i18n, that script throws a ReferenceError and the PDF loses its font.

Now a small helper add_pdf_font_script() attaches it with wp_add_inline_script( super-common, ..., after ), so it always runs right after the localized object; if super-common was already printed (AJAX-loaded form / pending message), it falls back to the old footer output. The value is built with wp_json_encode. The font <style> output is unchanged.

Base branch

release/6.4.x: bug fix for the beta channel. LTS counterpart: separate PR.

Tests

new tests/test-pdf-font-inline-script.php:
  without the fix: 2 of 3 fail (not attached to super-common; not printed after the localized var)
  with the fix:    OK (3 tests, 10 assertions); the third test guards the footer fallback
full PHPUnit suite: OK, 615 tests, 10295 assertions, 1 skipped

Merge

Draft: for QA and the next 6.4.0xx release session.

[RensTillmann]

The fix is already released in 6.4.010 (release PR #299, merged 21 Oct 2026): add_pdf_font_script() is in src/includes/class-shortcodes.php (line 6913, called at line 6899), with escaped font URLs and one font per language per page on top. This PR's test file tests/test-pdf-font-inline-script.php was not part of that release and stays on this branch. The browser suite covers this on 6.4.010 (pdf-error-and-debug.spec.ts, passed).