This is a great pair of bugs to chase down — let me actually dig into the mechanism rather than guess.Good — now let’s chase the size issue too, and check whether cropping is really what breaks the spacing, or something else.Ghostscript installed. Let’s test whether it can actually subset the font down after the crop:Dug into both — here’s what’s actually going on.
The file size issue: confirmed, and it’s a real limitation.
I built a realistic test: a multi-page PDF with a properly embedded font (same structure real academic PDFs use —
FontFile2,Widths,ToUnicode), then ran it through the exact crop pipeline the tool uses. A single cropped paragraph came out to 86% of the size of the entire 4-page source document. I confirmed why: the embedded font program is the dominant object in the file, and when you copy one page, you inherit that page’s entire font — every glyph, not just the ones your paragraph uses. This isn’t a pdf-lib bug specifically; no lightweight PDF library (pypdf, pikepdf, pdf-lib) subsets fonts down to “just what’s used” during a page copy — that requires actually rewriting the font program (dropping unused glyphs, remapping tables), which is a much heavier operation. Real font subsetting during copy is basically a Ghostscript-class feature, not something that fits in a simple client-side tool.I tested the fix path too: running a cropped file back through Ghostscript with
-dSubsetFonts=truecut it by ~40% in my test, with text extraction still perfect afterward. For a real paper with a big math/symbol font, the savings would likely be much larger, since your one paragraph probably uses a tiny fraction of the glyphs the whole paper needed. I can’t build that into the browser tool itself — it’d mean shipping a multi-megabyte Ghostscript-in-WASM just to shrink files that started as a few hundred KB, which defeats the “simple tool” idea. But if size turns out to matter in practice (git/Obsidian bloat from doing this hundreds of times), the practical move is: cut normally in the browser tool, and if a file comes out oversized, hand me that one PDF and I’ll run it through a subsetting pass. Not automatic, but a real, tested fix when you need it.The missing-spaces issue: I tried hard to reproduce it and couldn’t — which is actually useful information.
Many academic PDFs (especially LaTeX output) don’t encode spaces as literal characters at all — they achieve word gaps purely through positioning numbers in the text-drawing commands. I built a test file that does exactly this, cropped it through the pipeline, and extracted text before and after: identical, spaces intact. I repeated the test with a proper embedded TrueType font (with its own
ToUnicodetable) — same result, no degradation. So for the two most common font structures, cropping doesn’t touch anything relevant to text extraction; the underlying instructions are copied byte-for-byte.That points me toward composite/CID fonts (
Type0, often withIdentity-Hencoding) as the remaining suspect — these are common in PDFs built with XeLaTeX/LuaLaTeX or produced by some publisher pipelines, and rely on a separateToUnicodeCMap object that’s a known trickier case for PDF-copying libraries in general. I don’t want to guess further without evidence. Could you check one of the affected PDFs’ font type — most readers show this under something like “Document Properties → Fonts” (Preview, Acrobat, etc. usually list each font’s type and encoding)? If it saysType0/CID/Identity-H, that confirms it and tells me exactly what to test next. Alternatively, if you can share one PDF that shows the bug, I can inspect it directly rather than guess at its structure.One other thing worth checking on your end meanwhile: try selecting that exact paragraph directly from the original PDF (not cropped) using the same app/method you used to test the crop. If spaces are missing there too, it confirms the encoding quirk is a property of the source file, not something the cropping introduces — which would mean it’s not fixable on my end at all, just a fact about how that particular PDF was produced.
*Source: Claude Sonnet ○˒ *