This is huge. I've felt like an outsider for years here because the gov uses a lot of online forms in PDF.
Embedded PDF viewer in Firefox 81 supports filling forms
211–220 of 384 posts
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#212A 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…
What comes with Adobe Reader?
I have it on my work computer and haven't noticed anything I would rate as particularly obnoxious, but I don't use it much.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#213I just want to smooth scroll with vim keys (hjkl). Too much to ask? :/
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#214Earlier quoted context omitted.
As someone working on formats, I disagree with your generalization. But let's get into specifics. List the things about PDF that you believe can't be done with web pages?
Going to a particular page and only having to render that one page. Large HTML documents are unwieldy.
The modern web is slow for a lot of reasons, but none of them are about rendering lots of static html. Anyway just break things up into multiple pages if necessary.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#215I just want to smooth scroll with vim keys (hjkl). Too much to ask? :/
How is that relevant to this thread?
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#216Can we just get support for math text? For years I accidentally print research papers from the browser only to have to open it back up in a non-browser PDF reader and reprint.
With that and form fill I basically don't need another PDF reader, which is nice.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#217Sheesh, 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…
No, it's like Chrome including a PDF viewer.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#218I'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'…
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.
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#219Earlier 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").
> 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 with a lot that were like that from various source. Try explaining that...
Re: Embedded PDF viewer in Firefox 81 supports filling forms
#220Earlier quoted context omitted.
> feature parity Like PDF support?
That’s what OP said yes. That features like PDF fill is essential while things like Pocket are basically non-core side projects.
Pocket is an acquired company, the integration with FF has been minimal (it does less than the Chrome extension ;)) and I'm pretty sure it pays for itself.