About time.
Embedded PDF viewer in Firefox 81 supports filling forms
351–360 of 384 posts
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#352Earlier quoted context omitted.
The digits of pi contain every pdf that ever could and ever will exist.
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?
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.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#353Earlier quoted context omitted.
Only the standardized acroforms. XFA forms are deprecated anyway... http://blog.pdfshareforms.com/pdf-2-0-release-bid-farewell-x...
ISO deprecating it won't actually improve things at all, surely? It's Adobe that has the power and created the problem.
Adobe was part of the standards making process...presumably it wouldn't have been deprecated if they wanted to continue using it indefinitely.
https://blog.adobe.com/en/publish/2017/08/08/taking-document...
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#354Earlier quoted context omitted.
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").
Where did I say PDFs have to be in text format? I said every PDF has an equivalent text-only representation. The format, like postscript and eps started as text-only. Compression, making the files binary was added as an afterthought, to make files smaller (much smaller). If it were binary from the start, its designers would not have made the table of contents at the end waste bytes by writing offsets in ascii. See ht…
"OK, they added various ways of data compression, but PDF is, basically, a text-based format."
You are trying to move the goal post here. The above statement is simply untrue, PDF is not a text based format and it's that simple.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#355Earlier quoted context omitted.
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.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#356Earlier quoted context omitted.
Well, no, we can't just do that. But it's nice to dream.
Well, yes, we can, but the outcome will be far worse. The naive imagine "something better." The real world will interpret "better" as 27 half baked alternatives, 2 of which will work on something other than Chrome running on Windows.
OK sure, let's just do it then. Let's start... now. Is it happening yet? Can't we just do it?
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#357I 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.
Years ago, I worked on a project that required generating PDF invoices. Used the FPDF library and I was shocked how small the files are (including a properly sized logo) when generated compared to most other PDFs 'rendered' from word or print processors.
I just had to do tech support for someone whose 3 MB PowerPoint of text and some shapes became a 70 MB PDF that they couldn’t send through email anymore :/
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#358Earlier quoted context omitted.
I didn’t get it. Are you implying that coding PDF is an onerous task?
Check out the specs file for PDF and you will understand. I will be extremely surprised if anyone (besides Adobe) has implemented 100% of it.
I’d be surprised if Adobe has implemented 100% of it. With a format this complex, there’s bound to be discrepancies between the spec and the code they have.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#359Earlier quoted context omitted.
"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".
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#360Earlier quoted context omitted.
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.