Description of the bug
Documentation bug, not a library bug. Appendix 4: Performance Comparison Methodology, section "Files used", says each file comes with its "download link". Nobody can actually download the eight benchmark files, for two separate reasons:
-
The table renders no links. In docs/app4.rst the names are written as `adobe.pdf` (interpreted text) rather than `adobe.pdf`_, so the eight targets defined at the bottom of the file (lines 470–477) are never used. The rendered page has zero hrefs to artifex.com/samples/pdf/.
-
The targets are gone anyway. All eight return 404 today, and so do https://artifex.com/samples/pdf/ and https://artifex.com/samples/:
https://artifex.com/samples/pdf/adobe.pdf 404
https://artifex.com/samples/pdf/artifex-website.pdf 404
https://artifex.com/samples/pdf/db-systems.pdf 404
https://artifex.com/samples/pdf/fontforge.pdf 404
https://artifex.com/samples/pdf/pandas.pdf 404
https://artifex.com/samples/pdf/pymupdf.pdf 404
https://artifex.com/samples/pdf/pythonbook.pdf 404
https://artifex.com/samples/pdf/sample-50-MB-pdf-file.pdf 404
So the published timings can't currently be reproduced from the docs.
How to reproduce the bug
curl -sL https://pymupdf.readthedocs.io/en/latest/app4.html | grep -c 'artifex.com/samples' # 0
curl -s -o /dev/null -w '%{http_code}\n' https://artifex.com/samples/pdf/adobe.pdf # 404
The files do still exist in the Wayback Machine, byte for byte. I checked each archived copy's Content-Length against the "Size (bytes)" column of the table, and all eight match exactly:
| File |
Size in table |
Archived copy (raw, id_) |
| adobe.pdf |
32,472,771 |
20230327230046 → 32,472,771 |
| artifex-website.pdf |
31,570,732 |
20230517230115 → 31,570,732 |
| db-systems.pdf |
29,326,355 |
20240421152039 → 29,326,355 |
| fontforge.pdf |
8,222,384 |
20230517230115 → 8,222,384 |
| pandas.pdf |
10,585,962 |
20240423040027 → 10,585,962 |
| pymupdf.pdf |
6,805,176 |
20240421152031 → 6,805,176 |
| pythonbook.pdf |
9,983,856 |
20230517230115 → 9,983,856 |
| sample-50-MB-pdf-file.pdf |
52,521,850 |
20240421183811 → 52,521,850 |
Possible fixes, your call which:
- re-upload the eight files wherever Artifex now hosts samples, and add the missing trailing
_ in the table so the links render; or
- point the eight targets at the archived copies above (and add the
_).
I didn't open a PR because the first option needs someone with access to artifex.com. If you'd rather have the second, I'm happy to send one.
PyMuPDF version
Not version-specific: this is in the docs. Checked against main at a7ff9a3 and the live /en/latest/ page on 2026-09-19.
Operating system
n/a (checked from Linux)
Python version
n/a
Disclosure: I build a hosted HTML-to-PDF API, which has nothing to do with this issue. I found the dead links while running a link check over the docs of several PDF libraries. An AI assistant (Claude Opus 5, Anthropic) ran that check and helped me write this issue. Every status code and byte count above was measured before posting.
Description of the bug
Documentation bug, not a library bug. Appendix 4: Performance Comparison Methodology, section "Files used", says each file comes with its "download link". Nobody can actually download the eight benchmark files, for two separate reasons:
The table renders no links. In
docs/app4.rstthe names are written as`adobe.pdf`(interpreted text) rather than`adobe.pdf`_, so the eight targets defined at the bottom of the file (lines 470–477) are never used. The rendered page has zerohrefs toartifex.com/samples/pdf/.The targets are gone anyway. All eight return 404 today, and so do
https://artifex.com/samples/pdf/andhttps://artifex.com/samples/:So the published timings can't currently be reproduced from the docs.
How to reproduce the bug
The files do still exist in the Wayback Machine, byte for byte. I checked each archived copy's
Content-Lengthagainst the "Size (bytes)" column of the table, and all eight match exactly:id_)Possible fixes, your call which:
_in the table so the links render; or_).I didn't open a PR because the first option needs someone with access to artifex.com. If you'd rather have the second, I'm happy to send one.
PyMuPDF version
Not version-specific: this is in the docs. Checked against
mainat a7ff9a3 and the live/en/latest/page on 2026-09-19.Operating system
n/a (checked from Linux)
Python version
n/a
Disclosure: I build a hosted HTML-to-PDF API, which has nothing to do with this issue. I found the dead links while running a link check over the docs of several PDF libraries. An AI assistant (Claude Opus 5, Anthropic) ran that check and helped me write this issue. Every status code and byte count above was measured before posting.