For this blog post, we compared four available PDF-processing methods—pdftotext, docling, scrp-vision, and scrp-marker—on the same 52-page economics research article. The test document is a born-digital manuscript containing body text, multi-column regression tables, display equations, and embedded raster charts. The outputs were evaluated on:

  • speed
  • quality of the text
  • quality of the tables
  • quality of the display equations
  • quality of the charts

Summary of Results

Method Speed Text Tables Equations Charts
pdftotext ~0.2 s Good Good Raw but present None
docling (GPU, no OCR) ~33 s Best Excellent Dropped Images extracted
docling (GPU, OCR) ~35 s Best Excellent Dropped Images extracted
scrp-vision (summary) ~2 min Good Excellent Omitted Best
scrp-vision (verbatim) ~13 min/chunk Excellent Excellent Best Best
scrp-marker ~20 min Excellent Best Partial Images extracted

For a text-and-tables document, docling (run on GPU) gives the best quality-to-speed ratio: clean markdown, accurately reconstructed tables, and readable prose in about half a minute—but it drops display equations entirely, so it is unsuitable when math matters. scrp-vision is the only method that actually reads the charts (chart type, axes, visual takeaways) and the only one that recovers display equations (as LaTeX, in verbatim mode); it is therefore indispensable when figure or equation content matters, at the cost of much longer run times. scrp-marker matches docling on prose/tables and additionally extracts figures as image files, but is roughly 20× slower and memory-hungry. pdftotext is instantaneous and at least preserves equation tokens as raw text, but leaves line-number artifacts and cannot see charts.

Method comparison

Speed of processing

Method Wall time Notes
pdftotext ~0.2 s Local binary; no model loaded.
docling (GPU, no OCR) ~33 s gpu docling on the GPU partition; layout + table models on GPU.
docling (GPU, OCR) ~35 s Same, with OCR enabled; OCR adds only ~2 s.
scrp-vision (summary) ~2 min Remote vision API; 8 chunks run in parallel; figures add ~1 min.
scrp-vision (verbatim) ~13 min/chunk Output length drives time; a verbatim transcript is ~7× longer than a summary.
scrp-marker ~20 min srun, 16 CPU / 64 GB; CPU-only layout + OCR + table models.
  • pdftotext is effectively instant and runs anywhere.
  • docling (run on GPU via gpu docling) processes the whole document in ≈33 s without OCR and ≈35 s with OCR—roughly twice as fast as the CPU run (≈60–68 s). For a born-digital PDF with a clean text layer, the OCR and no-OCR outputs are identical: docling uses the embedded text layer and only OCRs bitmap regions, so OCR adds negligible time and no change in output here. (On CPU, the default OCR backend further requires a writable model-cache directory; the GPU/base-environment setup avoids this.)
  • scrp-vision must be chunked (uploading the full 52-page PDF triggers HTTP 413, Request Entity Too Large). In summary mode, 8 page-chunks run in parallel, so wall time is governed by the slowest chunk (≈2 min); total API time across all chunks is ≈13 min, but parallelism collapses the wall clock.
  • scrp-vision in verbatim mode is far slower because output volume is far larger—each text chunk takes ≈13 min.
  • scrp-marker is by far the slowest. On a plain login node it took >75 min and was killed (OOM, exit 137) during text recognition at ~10 GB RSS. Even with 16 cores / 64 GB via srun it required ≈20 min. This is the method’s decisive drawback.

Quality of the text

  • docling — Best. Produces clean, reading-order markdown with correct section hierarchy, no line-number noise, and intact prose. The one weakness is that display equations are dropped as <!-- formula-not-decoded --> placeholders.
  • scrp-marker — Excellent. Flowing prose, correct headers, footnotes handled as superscripts, equations rendered inline where simple. On par with docling, with marginally better equation/footnote handling.
  • scrp-vision (summary mode) — Good but lossy. With a default/summary prompt it returns a coherent natural-language digest rather than a verbatim record: excellent for comprehension, lossy as a record of exact wording. Page labels are chunk-local and occasionally wrong.
  • scrp-vision (verbatim mode) — Excellent, the most faithful text. Re-run with an explicit “transcribe verbatim, do not summarize” instruction, it reproduces body text, headings, and footnotes word-for-word and is the only method here that recovers display equations and inline CJK keywords that docling and marker drop or mangle. Two costs: (i) each text chunk takes ~13 min (vs. ~2 min for a summary) because output volume is far larger; (ii) two of ten chunks initially returned garbled output (fragments of unrelated tokens) and had to be re-run—verbatim transcription is less robust than summarization and benefits from a verify/retry pass.
  • pdftotext — Good but artifact-prone. The text layer is complete and accurate, but the source manuscript carries margin line-numbers (1–65 per page) that pollute the output, and two-column table regions are flattened. Usable, but requires cleanup before it reads well.

Quality of the tables

The document’s tables are multi-column regression tables (coefficients, standard errors in parentheses, significance stars, observation counts, F-statistics). All four methods recovered the numbers correctly; the differences are in structure and cleanliness.

  • scrp-marker — Best. Renders tables as tidy markdown with standard errors correctly nested beneath their coefficient, proper column headers, and no stray columns.
  • docling — Excellent. Also renders proper markdown tables with correct numbers; minor flaw is that standard-error rows are duplicated under the same row label rather than visually nested. Still fully usable.
  • scrp-vision — Excellent (both modes). Reconstructs tables as markdown with correct coefficients and correctly labelled standard-error rows, including multi-panel appendix tables. Slightly more prone to occasional column misalignment than docling/marker, but numbers are right.
  • pdftotext — Good (raw). With the -layout flag it preserves the spatial layout, so coefficients and standard errors are present and readable, but not structured as a table—you get aligned plain text with line-number interleaving. Fine for a human, poor for machine downstream use.

Quality of display equations

The document contains several display equations (a variable-construction formula and the baseline / IV regression specifications). Equation handling is a decisive differentiator and should drive tool choice when math matters.

  • scrp-vision (verbatim) — Best, and the only method that recovers equations. It transcribes display equations as proper LaTeX, preserving subscripts, fractions, and operators (e.g. \frac{...}{...}). This is the method to use when equations must be machine-readable.
  • scrp-vision (summary) — Equations omitted. The summary digest drops equations along with other verbatim detail.
  • docling — Poor: equations dropped. Every display equation is replaced by an HTML-comment placeholder, <!-- formula-not-decoded -->; the surrounding prose is retained (so it is clear an equation sat there), but the equation itself is gone. Enabling OCR does not help—the OCR and no-OCR outputs are byte-for-byte identical, including all placeholders, because these equations are vector text, not bitmaps. A secondary quirk: inline math fragments that docling does attempt are emitted as run-together Unicode math-italic symbols (e.g. the variable name “Population_ct” rendered as a single string of consecutive italic letters) with no subscript/superscript structure.
  • scrp-marker — Partial. Renders simple inline equations but struggles with complex display math; less reliable than scrp-vision.
  • pdftotext — Raw but present. Dumps the equation’s character tokens as linear text (subscripts/superscripts flattened), so it is lossy but the content is not silently discarded as with docling.

Quality of the charts

The document’s charts are raster images with no extractable text layer (stacked bar charts, binscatter/scatter plots, dot-with-confidence-interval plots, event-study plots, and choropleth maps). This is where the methods diverge most sharply.

  • scrp-vision — Best (and the only method that reads charts). It identifies each chart’s type, reads both axes and their ranges, reports the legend/categories, and states the visual takeaway (direction, magnitude, significance). For the maps it even reads the color-scale bins. With a verbatim prompt it goes further, reading off the approximate numeric value of individual data points and bars, not just the qualitative takeaway. This is information none of the other tools can produce, because the charts are raster images with no text layer.
  • scrp-marker — Extracts images, does not describe them. Marker crops each figure out of the PDF and saves it as a JPEG, embedding ![](image.jpeg) in the markdown. This is valuable if you want the raw figure files, but the markdown itself contains no description of what the charts show—you must view the images separately. (In practice you would pair marker with a vision pass on the extracted images.)
  • docling — Extracts images as inline base64, does not describe them. Contrary to a common expectation, the default pipeline does export figures: each chart is embedded directly in the markdown as a base64 data URI (![Image](data:image/png;base64,...)), placed between the figure caption and its notes. In this document all 10 figures (7 main + 3 appendix) were extracted. As with marker, the markdown contains no textual description of what the charts show—you get the raw image but no chart-type or axis-range detail. (The base64 payloads are large: ~1.1 MB total here, dominating the 1.25 MB markdown file.)
  • pdftotext — None. Captures only the caption/notes text and has no access to the rendered chart at all.

Operational notes

  • docling: use the GPU wrapper. Run gpu docling <file> (base conda environment, GPU partition). It is roughly twice as fast as a CPU srun run and its OCR model cache is pre-populated, avoiding the PermissionError that occurs when a CPU/docling invocation tries to download OCR models into the read-only system conda environment. For a born-digital PDF with a real text layer, OCR is optional—--no-ocr and --ocr produce identical output—so --no-ocr is the safe default; enable OCR only for scanned/image PDFs.
  • scrp-vision size limit: uploading a large PDF returns HTTP 413 (Request Entity Too Large). Split into ≤8-page chunks with pypdf and run the chunks in parallel; aim figure pages separately for chart descriptions.
  • scrp-vision: prompt controls the output. A summary prompt returns a fast, lossy digest; a “transcribe verbatim” prompt returns faithful text (with equations and CJK keywords) but is much slower (~13 min/chunk) and occasionally produces garbled output that must be re-run. Check each chunk for garbage before relying on it.
  • scrp-marker resources: CPU-only and memory-hungry; on a login node it was OOM-killed (exit 137). Allocate ≥16 CPU and ≥64 GB via srun -p large.
  • pdftotext flag: use -layout to preserve table alignment.

Recommendation

  • For a fast text + table extraction of a born-digital PDF: docling (best quality/speed). Fall back to pdftotext for an instant rough pass. Caveat: docling drops display equations—do not use it as the sole tool when math matters.
  • When display equations must be recovered (as LaTeX): scrp-vision in verbatim mode—the only method that captures them. Run it on the equation-bearing pages; budget the extra time and verify each chunk.
  • When charts/figures must be understood: scrp-vision—the only method that interprets visual content. Chunk large PDFs.
  • When you need a verbatim record of the text (exact wording, equations, non-ASCII keywords): scrp-vision in verbatim mode; budget the extra time and verify each chunk.
  • When you need extracted figure image files plus clean tables/text and can afford ~20 min: scrp-marker (with adequate srun resources).
  • Best combined workflow for a math-heavy paper: docling for text+tables, plus scrp-vision (verbatim) on the equation- and figure-bearing pages.