pdfrender.Rasterize does not finish in 600 seconds on a 328 KB gnuplot figure that mutool draw -r 150 renders in under one second.
Reproduction
The file is an arXiv figure — a matrix sparsity plot produced by gnuplot 4.6 through epstopdf:
/Users/Shared/axc/work/2302.04180/pipe-tmt_unsym.pdf 328 KB
/Users/Shared/axc/work/2302.04180/std-tmt_unsym.pdf 339 KB
data, _ := os.ReadFile(path)
start := time.Now()
img, err := pdfrender.Rasterize(data, 150) // 150dpi, one page
fmt.Println(time.Since(start), err)
Timed against the other ten figures of the same paper:
|
|
| nine figures |
≤ 2.4s |
pipe-tmt_unsym.pdf |
> 600s, no result |
std-tmt_unsym.pdf |
> 60s |
mutool draw -r 150 on the same file |
< 1s |
What the file contains
1.9 MB of decompressed content stream, counted by operator:
m 49517 l 65304 S 49463 f 18
So roughly fifty thousand separately stroked subpaths, each two or three points — one per matrix entry. No shadings, no patterns, no images, no transparency. An independent renderer handles it instantly, so the cost is not in the content.
The shape of the numbers (fifty thousand strokes, minutes rather than the ~2s the other figures take) suggests per-stroke work that is superlinear in the number of subpaths — a rasteriser state rebuilt per S, or a path buffer copied each time.
Why it matters here
go-tex/engine wires this behind GOTEX_PDFRENDER so a vector figure typesets at its true height instead of framing a placeholder. Measured over 100 arXiv papers with the gate open, the effect on page-count error is a small gain (−4) — except that two papers never finish and score as total content loss (+334). Both of those papers are this bug. Fixing it is what lets the gate open.
pdfrender.Rasterizedoes not finish in 600 seconds on a 328 KB gnuplot figure thatmutool draw -r 150renders in under one second.Reproduction
The file is an arXiv figure — a matrix sparsity plot produced by gnuplot 4.6 through
epstopdf:Timed against the other ten figures of the same paper:
pipe-tmt_unsym.pdfstd-tmt_unsym.pdfmutool draw -r 150on the same fileWhat the file contains
1.9 MB of decompressed content stream, counted by operator:
So roughly fifty thousand separately stroked subpaths, each two or three points — one per matrix entry. No shadings, no patterns, no images, no transparency. An independent renderer handles it instantly, so the cost is not in the content.
The shape of the numbers (fifty thousand strokes, minutes rather than the ~2s the other figures take) suggests per-stroke work that is superlinear in the number of subpaths — a rasteriser state rebuilt per
S, or a path buffer copied each time.Why it matters here
go-tex/engine wires this behind
GOTEX_PDFRENDERso a vector figure typesets at its true height instead of framing a placeholder. Measured over 100 arXiv papers with the gate open, the effect on page-count error is a small gain (−4) — except that two papers never finish and score as total content loss (+334). Both of those papers are this bug. Fixing it is what lets the gate open.