Live data from Hacker News

Embedded PDF viewer in Firefox 81 supports filling forms

support.mozilla.org

261–270 of 384 posts

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#261

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.

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#262

Earlier quoted context omitted.

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

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#263

Earlier quoted context omitted.

PDF.js dev here. I'm a bit confused on which part of internal API you would like to use? The way I think of it, there are really three API's in pdf.js: 1) Main thread API (api.js) which we base the version off 2) The code that runs in the worker 3) The viewer components (web/*) Quite awhile ago when we decided what parts of the API to version, we thought more people would want to use #1. Now that the project is matur…

> PDF.js dev here I'm so sorry about being forward but why the hell don't the vim keys (hjkl) smooth scroll? Its so frustrating. Is there an option to set it as so? Using the arrow keys is so cumbersome.

Because not everyone uses Vim?

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#264
post #178
post #45

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

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#265
post #219

Earlier quoted context omitted.

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

I never dug deeper into it, so I am not aware of why it does that or if it's a specific version or whatnot, but take a PDF from which you can extract the text (with pdftotext/pdfbox for example). Open it in the document viewer and "print" it to PDF. If you extract the text again it is not readable anymore. This wouldn't be an issue if it was a conscious choice, but when I parsed a lot of born-digital PDFs we ended up…

Could it be “compacting” the fonts? So if U+0000 to U+0007F aren’t used at all, remove those glyphs and set U+0000’s glyph to be what was U+0080? Yes, I know NULL doesn’t have a glyph, but I hope that gets the idea across.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#266
Will it support only the standardised kind of forms, or also the proprietary Adobe-only kind of forms? (Yes, there's two, and the latter are what Swedish administrative agencies use, so I'm forced to choose the “non-fillable PDF” option lest I get a file intentionally made unreadable to non-Adobe software.)

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#267
post #87

Earlier quoted context omitted.

OK, they added various ways of data compression, but PDF is, basically, a text-based format. As far as I know, any PDF can be losslessly converted to an equivalent PDF that can be edited in any text editor, even Notepad. And yes, you could fill in the forms there, too (if you were stubborn enough)

That’s news to me and Bluebeam’s PDF search feature! It turns out you can make PDFs (This usually happens with architectural drawings) that are comprised purely of images that are not searchable, and therefore you are wrong. I silently thank every architect that provides searchable PDFs, it makes my job way easier

GP is right. The code that makes up a PDF is text-based. Those images can be encoded in the PDF file using the ASCIIHexDecode filter, i.e. as editable ASCII text code.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#268
post #87

Earlier quoted context omitted.

OK, they added various ways of data compression, but PDF is, basically, a text-based format. As far as I know, any PDF can be losslessly converted to an equivalent PDF that can be edited in any text editor, even Notepad. And yes, you could fill in the forms there, too (if you were stubborn enough)

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.

Re: Embedded PDF viewer in Firefox 81 supports filling forms

#269
post #166

Earlier quoted context omitted.

Does your operating system not support this natively from the print dialog?

On Windows at least, using the built-in PDF printer with Firefox results in text in the PDF file being converted to paths (not text). Huge file and you can't copy/paste. I've tried 3rd party PDF printers (PDFForge) and the result is the same, so I think it might a FF bug (or feature)? Chrome's save-as PDF produces actual text. It's the main reason I still have chrome installed.

There must be something strange your particular set up, or maybe the behavior changes based on the page. Firefox 81, Windows 10 version 2004, multiple computers, printing this page with the "Microsoft Print to PDF" printer this page of comments all result in a PDF of ~470KB with selectable text.
Post reply on HN