Why I'm filing this
Tectonic carries vendored C from TeX Live (XeTeX, dvipdfm-x, etc.). Those copies fall behind upstream over time, and fixes that landed upstream years ago just never reach Tectonic users. Nothing checks for that on a schedule, so it only turns up when someone hits a bug and bothers to trace it back to a missing commit.
#1377 is a clean example. A few macOS CJK system fonts (STHeiti / STXihei / STFangsong) expose only a (platform 0, encoding 4) cmap subtable. Tectonic doesn't handle that case, so it writes no /ToUnicode CMap and the text comes out non-selectable and non-copyable in the PDF. The fix is a single { 0, 4 } entry in the vendored dpx-tt_cmap.c and dpx-cidtype2.c. That entry was added upstream in 2022 ("cidtype2.c, tt_cmap.c: Support some TrueType fonts in macOS which use 0-4 cmap", texjporg/tex-jp-build, 2022-06-15, Clerk Ma). About four years upstream, never crossed over. Compile the same document with XeLaTeX from TeX Live 2026 and it copies fine.
Nobody finds that without a user debugging cmap subtables by hand. A periodic look at upstream would have caught it for free.
What I'd suggest
A recurring review (quarterly, or tied to the annual TeX Live release) that diffs the vendored sources against current upstream and decides what's worth pulling in. Roughly:
- Record, per vendored component, where it came from and which upstream commit / TeX Live version it was last synced from. A small manifest, or just notes in each crate's README/CHANGELOG. Right now you can't easily tell how stale a given file is.
- Automate the diff: a scheduled job fetches the upstream trees (
tex-jp-build, dvipdfm-x, XeTeX) and lists commits touching vendored files since the last sync.
- Triage what comes back (backport / ignore / look closer) and open issues or PRs for the worthwhile ones.
The middle step is mechanical enough to hand to an agent on a schedule (fetch, diff, summarize, classify) and have a human only approve the backports. That's the part I actually care about.
Why now
#1377 shows the drift is real and hits users (broken copy/paste in CJK PDFs on macOS). The same area has other open reports (#1375, #1345, #924, discussion #915), and some of those might also have upstream fixes nobody pulled in. A standing process would surface these instead of catching them one font at a time.
Happy to help prototype the diff tooling if there's interest.
Why I'm filing this
Tectonic carries vendored C from TeX Live (XeTeX,
dvipdfm-x, etc.). Those copies fall behind upstream over time, and fixes that landed upstream years ago just never reach Tectonic users. Nothing checks for that on a schedule, so it only turns up when someone hits a bug and bothers to trace it back to a missing commit.#1377 is a clean example. A few macOS CJK system fonts (STHeiti / STXihei / STFangsong) expose only a
(platform 0, encoding 4)cmap subtable. Tectonic doesn't handle that case, so it writes no/ToUnicodeCMap and the text comes out non-selectable and non-copyable in the PDF. The fix is a single{ 0, 4 }entry in the vendoreddpx-tt_cmap.canddpx-cidtype2.c. That entry was added upstream in 2022 ("cidtype2.c, tt_cmap.c: Support some TrueType fonts in macOS which use 0-4 cmap", texjporg/tex-jp-build, 2022-06-15, Clerk Ma). About four years upstream, never crossed over. Compile the same document with XeLaTeX from TeX Live 2026 and it copies fine.Nobody finds that without a user debugging cmap subtables by hand. A periodic look at upstream would have caught it for free.
What I'd suggest
A recurring review (quarterly, or tied to the annual TeX Live release) that diffs the vendored sources against current upstream and decides what's worth pulling in. Roughly:
tex-jp-build,dvipdfm-x, XeTeX) and lists commits touching vendored files since the last sync.The middle step is mechanical enough to hand to an agent on a schedule (fetch, diff, summarize, classify) and have a human only approve the backports. That's the part I actually care about.
Why now
#1377 shows the drift is real and hits users (broken copy/paste in CJK PDFs on macOS). The same area has other open reports (#1375, #1345, #924, discussion #915), and some of those might also have upstream fixes nobody pulled in. A standing process would surface these instead of catching them one font at a time.
Happy to help prototype the diff tooling if there's interest.