Live data from Hacker News

Embedded PDF viewer in Firefox 81 supports filling forms

support.mozilla.org

331–340 of 384 posts

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#331
post #15

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.

I had a look through the XPS standard and had a similar feeling. I complained to a friend that had been involved in one of the bigger pdf libraries. He then made me compare it to his version of the pdf 2.0 (iirc) standard.

That is truly nightmare material. Especially considering a non-trivial percentage of pdfs circulating are non-conformant and people still expect them to render...

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#332

A note for Linux and macOS users, from someone who switched to windows one year ago: it’s maybe surprising but it is a VERY REAL pain in the Windows world to find a pdf reader that also allows you to edit forms, that doesn’t also come with malware or adware, and has even just a modest UX! So for sure you already have access to Evince and Preview.app, they already do everything you want, but Windows users don’t really…

Okular can "edit" forms. I have been doing this on Linux and Windows for a while. Not the most usable but it works. What I can't do in Okular, I do in Gimp. I will use Firefox for editable form pdfs but for those that don't have editable forms, I will continue to use Okular/Gimp. I actually stumbled across the ability to edit forms in Firefox only recently. I was like... What? This is amazing! For some reason the pdf…

As a PDF "editor" you may also like Libreoffice Draw. I was surprised how well it can work with PDFs!

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#335
post #100

Earlier quoted context omitted.

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").

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 http://blog.idrsolutions.com/?s=%22Make+your+own+PDF+file for more info on how to write PDF by hand (also shows why I said you have to be stubborn to do that)

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#336

Can we just step away from PDFs to a better standard? Every time I deal with PDFs or I have to on behalf of my parents it is a true waste of time and resources - there has to be a better way.

One of the reasons PDFs are still so common is they do their job pretty well, i.e. accurately displaying documents.

Any alternative would need some very compelling reason to use it instead. Take Microsoft’s XPS which I think is it’s closest rival. It is an open standard based on XML. It’s built into Windows, Office, and many printers support it natively along with major software vendors, but I can’t think of a single time I’ve come across an XPS file online.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#337
post #188

Earlier quoted context omitted.

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#338
post #268

Earlier quoted context omitted.

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…

More. Go here and download the PDF spec.: https://www.adobe.com/devnet/pdf/pdf_reference.html Look at Chapter 3, Syntax. The code is all text based. We are not talking about the visible characters in a PDF viewer, but the code of the PDF file itself.

[deleted]

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#339
post #199

Earlier quoted context omitted.

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 repres…

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#340
post #319

Earlier quoted context omitted.

What's your favorite PDF feature that causes a brain meltdown? I've read a few comments on HN how PDF is, well, not developer-friendly. If people are interested in providing some more examples here, I'd be curious to know!

I think one of the biggest pain points that developers hit that hasn't been mentioned here is content extraction. A lot of the time developers want access to the text inside PDFs. Unlike HTML or formats like MS Word (XML or old binary format) getting "text" isn't really possible. Most "document" formats have the concept of words or strings: a set of characters separated by whitespace. PDF isn't a "document" format in…

[deleted]
Post reply on HN