engine: search graphics extensions so \includegraphics{fig} resolves - #193
Merged
Conversation
loadImage read the reference name verbatim, so a figure written without its
extension — \includegraphics{fig}, the form real papers use — never found
fig.pdf/fig.png on disk and collapsed to a placeholder. This was the dominant
reason figures did not load even after a PDF rasteriser was wired (#191).
Resolve the reference the way graphicx does: an exact hit wins; otherwise, when
the name carries no known graphics extension, each extension is appended in turn
— pdf first, matching pdftex's \Gin@extensions, both cases for a case-sensitive
filesystem — and the first that exists is used. Existing-file resolution is
unchanged (os.Stat of the exact name still wins), so papers that already loaded
their figures are unaffected; only previously-failing extension-less references
now resolve.
Effect (GOTEX_PDFRENDER=1 GOTEX_FLOATS=1): 2206.00339's \includegraphics skips
fall 10 -> 0 and its page count reaches 34, exactly tectonic; 2201.02101's fall
11 -> 0. Where figures now load oversized (no \linewidth scaling yet) the page
count overshoots — a separate, isolated residual — but every figure that should
render now does. Tests cover exact hit, extension search, pdf-first ordering, an
honoured explicit extension, no-match, and a directory not counting as a file.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
loadImageread the reference name verbatim, so a figure written without its extension —\includegraphics{fig}, the form real papers use — never foundfig.pdf/fig.pngon disk and collapsed to a placeholder. This was the dominant reason figures did not load even after the PDF rasteriser was wired (#191) — the residual that PR flagged.How
Resolve the reference the way graphicx does: an exact hit wins; otherwise, when the name carries no known graphics extension, each extension is appended in turn — pdf first, matching pdftex's
\Gin@extensions, both cases for a case-sensitive filesystem — and the first that exists is used. Existing-file resolution is unchanged (os.Statof the exact name still wins), so papers that already loaded their figures are unaffected; only previously-failing extension-less references now resolve.Effect (measured,
GOTEX_PDFRENDER=1 GOTEX_FLOATS=1)\includegraphicsskipsEvery figure that should render now does; 2206.00339 reaches exact tectonic page count. Where figures load oversized (no
\linewidthscaling yet) the count overshoots — a separate, now-isolated residual (the next lever), not a regression.Tests cover exact hit, extension search, pdf-first ordering, an honoured explicit extension, no-match, and a directory not counting as a file. Full suite, vet, gofmt green.
🤖 Generated with Claude Code