What is the smallest possible valid PDF?
stackoverflow.com
stackoverflow.com
I did that here with tiny images in JPEG, PNG and GIF https://github.com/simonw/datasette-render-images/blob/maste...
That is, do you need a "valid PDF" detector or "more likely a PDF than anything else" detector?
Though when I think of "detector" I think more of https://en.wikipedia.org/wiki/File_(command) and not something which verifies the file is in the correct format.
file 'setupTests.ts' setupTests.ts: Java source, ASCII text
I wouldn't put too much trust in file.
But it will work fine for PDFs, often enough.
0 regex \^import.*;$ Java source
They should move those to a simple list in the README and reserve the repo for non-empty files.
Following the GitHub link (datasette-render-images) in the comment you replied to, there's a code comment with a link to the same library (small).
A minimal size file could easily catch some cases where your code assumes some sort of structure (some flag, header, metadata structure, etc.) exists when it's possible it actually doesn't.
Now what? Remember it was around the year 2000, what to use? Floppy disks of course! Saved it, looked at it and thought it had gone wrong somehow because it listed as 4KB only.
Used another floppy, lowlevel formatted with fdformat to be sure, taking minutes, hurry, hurry! Saved again.
4KB!? WT..?
Booted up another system, loaded the PDF with different readers, worked.
Shrugged and hoped it worked at the customers site also, which it did, they even said it looked nice and clear.
If only they knew...
Is the explanation really as lame as "They were there first and it stuck"?
There's certainly a lot of legacy embedded in PDF which doesn't help.
>Is the explanation really as lame as "They were there first and it stuck"?
I'm not sure they were first but they became dominant because... Adobe. And Adobe made it an open standard which pretty sealed the deal.
As an engineer I can see why you would find the spec inelegant.
But as an end-user, using it to fill in forms couldn't be easier.
Similarly macOS Preview (free) has an identical "Text" tool to add text anywhere.
I've never checked other programs, but those are certainly the two default tools one would use with PDF's on Macs.
Personally, I enjoy working with DeJaVu files very much but you only find those of pirated ebooks.
What makes PDF particularly challenging is that there are so many broken PDFs out there which must be tolerated and so many legacy fonts, images and formats which have accumulated in the format over time - JPEG 2000 anybody?
Most complaints I see about PDF though are usually “why can’t it just wrap lines” and the answer is that there’s a zillion ways to do that and we’re supposed to be representing the output of that process as a visual artifact, not the input, as HTML does, because the use case is printing and stability of the output is non-negotiable.
[0] https://github.com/mathiasbynens/small/blob/master/pdf.pdf
In means of "minimal valid raster image" - its raster image with 1px × 1px; in means of "minimal valid vector image" - its vector image with single dot OR single line segment.
But I can't imagine what is "minimal valid raster PDF" means.
Unfortunately, this is a valid measure of a "valid Pdf" - it doesn't mean the Pdf will work in other readers.
I've had some luck with qpdf --check - as far as I can recall, I've not seen problems with a file that passes.
http://qpdf.sourceforge.net/files/qpdf-manual.html#ref.testi...
Also worth looking into is mutools with its --clean option.
If you want a fully covered example it'll need a trailer, xref and at least one obj reference. ...and there are TWO flavors of those (linearized and not). ...and flate coded and not.
So, for a test harness you'd actually want a collection of small files.
https://github.com/minad/mimemagic/issues/4
https://github.com/minad/mimemagic/issues?q=is%3Aissue+is%3A...