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.
It sounds like you either know a lot more than me or a lot less than me. The PDFs I've dealt with don't store text as strings, they store it as individual characters. This left me having to write a heuristic based algorithm to group the characters into words, words into lines, lines into paragraphs, paragraphs into columns. Again, as far as I know, there are no heuristics good enough to get that right for all values…
He knows a lot less than you probably because there is absolutely no requirements for PDFs to be in text format and most aren't. The "text" he is editing could render to completely different characters depending on how the PDF document was created. The default MacOS PDF printer will actually remap the font cmap making born-digital PDFs where the "text" is something else entirely (say "$" maps to "a").
> The default MacOS PDF printer will actually remap the font cmap making born-digital PDFs where the "text" is something else entirely (say "$" maps to "a").
What? Why!? I've heard of doing that as a form of DRM, but I can't imagine Darwin defaulting to doing that.
Sheesh, what's with the hate for a generally all-round useful feature in an Open source browser? The last thing I want is to have to install 3rd-party software on my machine and have my browser be held hostage to it just to view PDF documents on the web. Being able to fill them in is a very useful feature and the in-browser PDF readers are still way less bloated than most other plugins.
Yes, this is a nice feature added to a basically-reasonable implementation of a PDF viewer. I think the objection is that that PDF viewer should be an actual independent application, not baked into a browser that already is too many things to too many people. It's like Chrome including a basic antivirus function (https://support.google.com/chrome/answer/2765944?co=GENIE.Pl...) - yes it's useful, yes I trust it more than a lot of AV products, but no I don't think it's reasonable to bundle it into the program that's supposed to be here to render web pages for me. (Similar arguments, to varying degrees, are made against WebRTC and Pocket)
I looked into coding PDFs once. Then I closed my MacBook (Pro) and went for a long walk into the ocean. I think I almost got to America, but then I turned and swam back again. Turnd out I had just fallen asleep and had a nightmare. I was actually just working with regular text files, and everything was fine.
It's really not that difficult if you read and understand the PDF specification. As a learning exercise, I created a simple PDF generator library that creates ASCII PDF documents (you can open them in Notepad) and includes comments about what each drawing instruction does.
I find it extremely convenient. Also I know a lot of security issues in PDF viewers are effectively solved by running it in the browser's JS sandbox.
You could also disable Firefox's built-in PDF viewer and instead use an external PDF viewer that doesn't even support Javascript.
Native PDF clients have had lots of security holes. In this case having the client written in JS means we can repurpose the battle hardened JS sandbox to also contain PDF exploits.
> It's an accessibility nightmare with no obvious advantage over simple ordinary webpages. It is easy to criticize something when you don't look back at the historical context through which it emerged. It has plenty of advantages over HTML but they're easy to dismiss if you don't have a use case for them.
> It has plenty of advantages over HTML but they're easy to dismiss if you don't have a use case for them. Can you discuss some of the advantages? The only advantage that comes to mind is that Apple has built-in support for writing PDFs and that has a lot to do with Adobe rather than PDF being a better candidate.
PDF's ubiquity is 100% that it printed the same (or close to same) on any postscript compatible printer. It's tech so old many in the industry ignore the reason it existed (and still exists). Every solution beyond PDF has also been either closed source (read Microsoft) or ignored. It's useful, that's why it exists. Yes, it's archaic, yes, it's hard to read for tech people, but for non tech people, it solves an issue that plagues the entire software industry: Standardization.
I'm the author of Polar ( https://getpolarized.io/ ) that uses PDF.js as its PDF backend. This is a somewhat big update for PDF.js which is kind of cool in that they haven't really been updating it as aggressively as they usually do in the last year or so. It's a bit frustrating to work with though. The entire concept of rendering a PDF via JS is fascinating but actually using the API has been a huge pain for us. We'…
Looks cool! On a sidenote, I've always been curious with product sites: what's your metric for including other orgs under "Used and Trusted by Top Organizations"? How do you know they use / trust it?