Did anyone try to pluck out PDFs from /dev/urandom? How about from radiotelescope feed? Maybe the first evidence of extraterrestrial life will be some poor alien's tax form?

The digits of pi contain every pdf that ever could and ever will exist.

"Find the earliest valid pdf in consecutive digits of pi"

I mean, the answer is trivially zero, there exists a PDF-like structure somewhere in Pi, and the offset of that doesn't have to be zero, it can start or end anywhere. So the range [0, N] is a valid PDF.

"Find the last byte of the first valid PDF in the binary digits of Pi"

Since the PDF also doesn't have to be end-aligned, the answer is trivially [0, infinity].

The first place a valid PDF could be ended, perhaps.

A pdf at [0, N] sorts before the one at [0, N+1], by "first valid pdf".

No, both start at 0. Also, [0, infinity] and [0, infinity+1] are the same thing.

your example fails to satisfy the invariant. 11 is less than infinity.

you're just pasting random python snippits at me now. It's time to move on.

again, just to summarize: PDF files do not have to be zero aligned, and they do not have to be end aligned. Therefore the answer to the question "what is the first segment of Pi that is a valid PDF file" is trivially (0,infinity). That is a correct statement. The non-greedy (in the regex sense) answer to that question will be different, however.

Why is this so hard? If the tuple (0,10) represents the range of a valid pdf, then the next tuple (0,11) is also a valid pdf. Or any after it up to and including (0,infinity).

Note the word "next", implying that (0,10) sorts before (0,11); you even say it yourself "11 is less than infinity". Where I'm from "first" and "less" are related (the first element in a unique sorted list is defined to be less than all other elements). So if there is any valid pdf in pi that can be identified by the range tuple (0,N), then the first valid pdf must occur before N -> infinity. Therefore (0,infinity) can never be the first valid pdf, even though it may be a valid pdf.

Maybe a picture would help:

    Potential pdf file ranges in pi: [(0,0),(0,1),(0,2),(0,3),(0,4),...,(0,N-1),(0,N),(0,N+1),(0,N+2),...,(0,infinity)]
    Is it a valid pdf?                 no    no    no    no    no  (no)  no      yes   yes     yes   (yes) yes
    Which one is first?                                                          ^^^

I thought linking to a python script that shows the order comparison of a tuple (0,N) as less than the tuple (0,N+1) would clearly demonstrate this, but it appears to have failed to communicate that to you. We don't need non-greedy regex rules to do a less than comparison.

Please don't give them any ideas.. the whiteboard interview coding tests are hard enough as it is

How else will we weed out the fakers and people coasting for 10 years? Our CRUD SaaS app needs top people.

Doesn't sound like that hard of a question, given you are provided the structure of the PDF header. I guess it really comes down to substring search.

Imagine if it was a PDF that simply rendered the number 42.

If that happens we know for a fact that we are in a simulation

Well maybe. We don't know if pi is a normal number.

Actually it only needs to be a disjunctive (or rich) number which is a weaker condition.

We don't know whether pi is that either for any integer base.

> We don't know if pi is a normal number.

Sure we do. There are plenty of proofs out there that pi is an irrational number.

Irrational does not imply normal. For example, 1.01001000100001... is irrational but it's certainly not normal.

Technically, 1.01001000100001... can be normal depending on what ... stands for. :)

Well, obviously. But presumably the ... is meant to imply that this is the summation of 1/(10^(x(x+3)/2)).

Or what 1 or 0 or . stands for.

Actually I'd argue the example you provided is normal, as long as you authorise a particular encoding where every number n you're looking for is encoded as a string of n zeros.

It's then trivial to see that every number you can think of is encoded in there, and therefore any data, piece of music or movie that ever existed.

(I'm not sure we're allowed to fiddle with the encoding, but since we allow ourselves to represent a piece of music into a number, we're already talking about encoding anyway, so it doesn't seem like cheating to me...)

Normality of a number is with respect to number bases, so your trick with encoding is invalid. Otherwise, every computable number could be considered normal - take an algorithm for generating of it, supply a random string (this is the encoding), disregard the random string, and you have a perfectly valid normal representation of your number. So it is cheating.

I agree that normality is a specific formalized concept, but you could always require that an encoding function like this is injective.

Encoding doesn't count. Normality is a very specific mathematical concept: https://en.wikipedia.org/wiki/Normal_number

Also, 1.01001000100001... is a good example of a number that is both irrational and transcendental but not normal.

Normal in this sense means that all the frequency of all digits approaches a uniform distribution as the length of the sample increases towards infinity. Basically if we could see "all of" π and count all the 0s, 1s 2s, 3s, &c to 9 all the counts would be equal.

That on its own can't be right, because 0.12345678901234.....

According to wikipédia, you gave a definition for "simply normal", and for normal numbers the distribution of any sequence of digits is uniform. So 00, 01, ..., 99 each occur uniformally too.

Moreover you need to consider it with regards to all other bases than 10 too.

Is this correct, mathematically?

I understand the point that PI contains every possible piece of information, theoretically.

However, the chance of finding a given string in PI depends on the string’s length. The longer the string, the more the probability tends to 0.

The paradox therefore is that PI contains every PDF, but you will never find them, so in what sense does it really contain them at all?

No, all strings theoretically exist in 𝛑 given enough digits, so longer strings don't reduce probability of existence, they just mean that it will take more digits to find them.

See Borell-Cantelli lemma.

I looked this up but I’m not sure I grasp your point.

Are you saying that:

- given a long string, we might ask “can this string be found in PI?”

- the probability of finding a long string in PI is infinitely small

- the number of possible strings in PI is infinitely large

- it’s not possible to decide if the answer is yes or no?

If a tree falls in the forest and no one is around to hear it fall. Or a modern take, if a disease has no symptoms is it really a disease.

<citation needed>

Including a PDF that generates the digits of pi

actually, if you find the citation, let me know, you might be in for an award

I'm not sure that's necessarily true. It is true (at least with a non-constructive proof) that if you pick a 'random' real number then it contains all possible PDFs with probability one ( or that the set of numbers for which this is not true has lebesgue measure zero). But I'm not sure it's known that pi has this property.

Pi is thought to be normal but it hasn't been proven yet, so we can't say that for sure, but it's likely true.

I don't think that is a proven fact.

Since a PDF can begin with non-PDF content, then pi itself is a valid PDF file.

My favorite pdf fact is that the security flags for things like copy protection and passwords are on the viewer to implement so you can just turn them off and all the security is gone

Debian actually goes out of their way to patch those checks out in their PDF-related packages as part of their stance against DRM, like this example with "pdftk":

https://sources.debian.org/patches/pdftk/2.02-4/drm_fix/

This is not entirely true, you can encrypt PDFs [1] since v1.3 of the spec but the cypher is often so weak (RC4 until v1.6) they can be bruteforced in reasonable amounts of time.

[1] https://www.pdflib.com/pdf-knowledge-base/pdf-password-secur...

You can encrypt them to completely prevent them from being opened. But cgb223 wasn't talking about that, cgb223 was talking about the ability to open them but not copy text, or not print.

You can make the text uncopyable by using non-standard font indexing. The reader will be able to copy the text but it will be gobbly-gook. It forces the user to OCR the PDF or reverse the font mapping.

And ain't that a treat when clients send us PDFs to sort, print, and mail, but the address extraction fails completely.

You can also circumvent copy protection on PDFs by taking a screenshot, or taking a photo of the screen with your phone.

My somewhat less favorite pdf fact is that if you do that, you are still breaking protection, legally speaking.

Seems to be a reasonable analogy with trespass, where you are violating the law when you cross an invisible line. The need for marking the line varies considerably.

And even places with strong roaming rights tend place limits on well marked land.

So what if you open it in a postscript viewer instead of a PDF viewer? Because they are compatible formats except for some edge cases like security flags.

Postscript and PDF are definitely not compatible formats. The drawing model is similar, but the structure and code are completely different.

On the other hand, this allows for some incredible polyglot files, like some of the tricks with PoC||GtfO issues where the file is a readable PDF but also a game cartridge and also a zip file with the proof-of-concept code in the issue. And the front cover has the MD5 hash of the whole file printed on it... but that's another trick entirely!

Yeah, next time I need a CV it'll be a single-file Ruby web server and PDF that's also an archive of its own sources.

I'm currently looking for a job as a Rails Developer. I might just do that.

Probably won't send it to any recruiters, but it will be a funny anecdote for interviews.

Can a PDF file contain a PDF file, and if so can that PDF file contain a PDF file?

Yes. Because the PDF standard specifies a mechanism that lets you "attach" files to a PDF :)

I worked for PDFTron on their WebViewer product earlier this year, and primarily spent time implementing this feature in JS. Understanding the spec on this was tricky, because standard PDF viewers need to be able to uncompress the stuff you jam in there. It kind of blew my mind that you can literally jam any arbitrary file into a PDF.

ZIP files can: https://research.swtch.com/zip

My stupid bank sends encrypted attachments as an encrypted PDF with HTML file attached.

Yes.

I never understood that Google security blog post on how they could make 2 different PDFs with different content have the same SHA but now that you mention you can stuff bytes in a file unrelated to the PDF, it makes sense...

It'll depend on the pdf reader you're using, but I'm pretty sure the PDF header needs to start in the first 1K of the file.

Some readers won't need a header at all, I think. Near the end (usually!) of the file there's an index of objects (page data etc.) with byte offsets, which can point to anywhere in the file.

I can never find the PDF hack talk where author explains all 100 ways to embed things in pdf or pdf into things

It's hidden in a PDF in the digits of Pi.

You can imagine the pain when you need to reliably detect PDF mime type on web proxy, or something like...