371–380 of 384 posts
Earlier quoted context omitted.
Unlock form in multiple ways (easy to google). Convert to acroforms using Acrobat Pro using the extract function. https://imgur.com/a/3mAi3l0 Will remove XFA "capabilities", but otherwise works...
This is really helpful, thank you! Will make my citizen ship application a lot easier :D
PDF support in Firefox is one of the most important additions in recent years. My gripe with Mozilla was they're pursing all these side projects when they really should be targeting feature parity with Chrome. That's the only way people will ever switch.
> feature parity Like PDF support?
Earlier quoted context omitted.
My favourite PDF fact is that it doesn't have to start at the beginning or end at the end of a file. Any sea of bytes that contains a PDF file is an acceptable PDF file...
Can a PDF file contain a PDF file, and if so can that PDF file contain a PDF file?
Earlier quoted context omitted.
That's great because it creates client expectations regarding what my PDF application should support. Implementing the spec is not good enough, you have to do what PDFium or Adobe do.
On the other hand, if they never supported those broken PDFs to begin with, we wouldn't have them in the wild and wouldn't have to deal with them.
I have a feeling this thread has a strong bias from highly automated valley life. In more provincial regions and even just much of Europe lots of forms have to be filled out and printed. It is not something you have to everyday or something, but the existing solutions suck massively. You either have to use Adobe, which requires Windows (or Mac, I suppose) and your firstborn or use some massively shady online service.…
Isn’t evince capable of this and the default PDF viewer on GNOME?
Earlier quoted context omitted.
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.
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?
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'…
Earlier quoted context omitted.
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".
Earlier quoted context omitted.
I am actually interested in doing pure JS pdf processing. All of the web interfaces for PDF processing are server side — which means it’s tough to process large files. The dream is a purely JavaScript solution that never leaves the local computer. I’ve got a few client-side success stories that do fairly significant image generation through the canvas. So far PDF seems reasonably manageable through manipulating the t…
> The dream is a purely JavaScript solution that never leaves the local computer. Mozilla's pdfjs[1] project is a pure HTML/JavaScript solution for PDF rendering. This is the same code that ships in Firefox browser as well. This is standalone, AFAIK, it doesn't talk to a mothership. [1] https://mozilla.github.io/pdf.js/
Earlier quoted context omitted.
I posted a link (above) to the app I built to solve that problem. The vast majority of form is indeed not « ready » for input, requiring users to go through hoops to fill them. And that work is done again by the next person.
I wasn't referring to any problem. Again, all those PDFs I wrote about are intended for reading only; no filling in, signing or other form of interaction other than reading letters that form words on a page is involved in any way, and that is entirely fine and how it should be, so both the PDF itself and a PDF reader that has no form-filling functionality would be entirely fit for purpose (notice the word "reader").
The problem I was referring to, is when one is expected to fill a PDF that was not built to be filled, such as the scan of a paper form.