mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-31 05:28:09 -06:00
Nick Nyssen
79cfdc0020
Round-6 review caught that this branch rejected is_file() for one path and kept using it forty lines above. The family loop filtered candidates with is_file(), which follows symlinks, so an entry that exists but no longer resolves was classified "not installed" and skipped — exactly the defect this branch fixes elsewhere. Now both blocks share one rule: presence via symlink_metadata, then a hard requirement that the entry resolves. Absence is still tolerated and reported; a broken entry fails loudly with the family named, because that is the failure we are trying to catch rather than a machine difference. Checked against this Mac first: no family or last-resort path is present-but-dangling here, so the stricter rule cannot produce a spurious red on current macOS. Also corrected two stale comments — the tripwire test is separate from the layout test *below* it, and the oracle's doc comment now states the exception the PR description already does: a Mac where nothing in the list covers Devanagari fails, since such a machine cannot validate anything. Verified solo on macOS 26.6 (Apple M5 Max), no concurrent writers this time: fmt --all clean; clippy -D warnings all-targets quiet; system_fonts 13 passed with and without PDFCRAFT_SYSTEM_FONTS=0; whole crate 1341 passed / 0 failed / 5 ignored; xtask layers (37 crates) and assets (272/6/22). Mutation evidence for the change, via font folders redirected to /tmp so system paths were untouched: with a dangling DevanagariMT.ttc in the system folder the current code fails at "exists but does not resolve", while reverting to is_file() filtering makes the identical defect pass silently. Re-ran the pinned regressions too: cap raised to 512 MiB, MAX_FACES cut to 1, probe swapped to Arabic alef, last_resort derived from first(), misspelling restored — all red.