Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing form filling and accessibility in the Firefox PDF viewer

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#41

Post by zinekeller »

muizelaar wrote: post #36
zinekeller wrote: post #19

Earlier quoted context omitted.

Mozilla developers at the time actually have other plans with the Pepper plugin support: Adobe Flash (since that Chrome's Pepper Plugin API (PPAPI) is actually miles better and secure than the Netscape [-era - ed.] Plugin API or NPAPI). They abandoned Mortar when Adobe have announced that it will retire Flash. (Also, PDF.js is now a misnomer: it now mainly uses WebAssembly.)

It doesn't. -------------------------------------------------------------------------------- Language Files Lines Blank Comment Code -------------------------------------------------------------------------------- JavaScript 355 144428 13069 16759 114600 JSON 12 24385 2 0 24383 CSS 12 3302 407 183 2712 HTML 32 1638 176 230 1232 Markdown 19 733 221 0 512 TypeScript 1 20 4 2 14 CoffeeScript 1 15 2 0 13 YAML 1 4 0 1 3 -…

I'm referring to the one built-into Firefox, not the HTML version. Even comparing the HTML one, this is misleading: the PDF.js compilation step means that there are WebAssembly code written nominally in JavaScript, namely those that handles font rendering and complex graphics (before pushing into the canvas, which by necessity is done in JS).

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#42

Post by gervwyk »

emilsedgh wrote: post #29

PDFJS is fantastic. But PDFJS folks, how can you do such a subpar job at documentation? There is really no documentation available on pdfjs. Or a proper changelog. Like in this article they talk about JS execution in pdfjs. And how they have a solution called quickjs. _no_ documentation whatsoever about how to use it. This has been their documentation for years: https://mozilla.github.io/pdf.js/api/ Had I created som…

Shameless plug. I recently wrote an article for Lowdefy (co-founder here) for using pdfMake with Lowdefy to generate pdfs. Works really great and easy, perhaps the next step is to add a pdf render block using pdfJs.

See the article: https://docs.lowdefy.com/generate-pdf-document-from-data

(edit: confused pdfJs for jsPdf)

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#43

Post by c0nsumer »

muizelaar wrote: post #35
c0nsumer wrote: post #34

I wish the Firefox PDF viewer performed a little better... Lately as I've been working on mapping projects and want to view large PDFs I've found many which need to be saved and opened in Preview.app instead of the browser. This is a great example of a map which views horribly in Firefox (try zooming in) but works great in Preview.app: https://www.bia.gov/sites/bia.gov/files/assets/public/webtea...

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1736108 for that case.

Well, thank you!

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#44

Post by glandium »

zinekeller wrote: post #41
muizelaar wrote: post #36

Earlier quoted context omitted.

It doesn't. -------------------------------------------------------------------------------- Language Files Lines Blank Comment Code -------------------------------------------------------------------------------- JavaScript 355 144428 13069 16759 114600 JSON 12 24385 2 0 24383 CSS 12 3302 407 183 2712 HTML 32 1638 176 230 1232 Markdown 19 733 221 0 512 TypeScript 1 20 4 2 14 CoffeeScript 1 15 2 0 13 YAML 1 4 0 1 3 -…

I'm referring to the one built-into Firefox, not the HTML version. Even comparing the HTML one, this is misleading: the PDF.js compilation step means that there are WebAssembly code written nominally in JavaScript, namely those that handles font rendering and complex graphics (before pushing into the canvas, which by necessity is done in JS).

There is no wasm in the version built-into Firefox.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#45

Post by gervwyk »

gervwyk wrote: post #42
emilsedgh wrote: post #29

PDFJS is fantastic. But PDFJS folks, how can you do such a subpar job at documentation? There is really no documentation available on pdfjs. Or a proper changelog. Like in this article they talk about JS execution in pdfjs. And how they have a solution called quickjs. _no_ documentation whatsoever about how to use it. This has been their documentation for years: https://mozilla.github.io/pdf.js/api/ Had I created som…

Shameless plug. I recently wrote an article for Lowdefy (co-founder here) for using pdfMake with Lowdefy to generate pdfs. Works really great and easy, perhaps the next step is to add a pdf render block using pdfJs. See the article: https://docs.lowdefy.com/generate-pdf-document-from-data (edit: confused pdfJs for jsPdf)

Sorry I confused pdfJs for jsPdf.

Perhaps the next step is to build a Lowdefy block that uses pdfJs to render pdfs :)

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#46

Post by sudosysgen »

InitialLastName wrote: post #7

Why is it that, a ~decade since MacOS started including forms and markups in their default PDF app (Preview) there still isn't a sane PDF editor for Windows? Chrome and Firefox's PDF viewers don't have editing, Edge has editing and forms but bonkers window management (sometimes PDFs open with Edge but not in an Edge window). Adobe Reader DC still tries to ship with malware, and is license-restricted. What gives?

Okular works.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#47

Post by evmar »

InitialLastName wrote: post #7

Why is it that, a ~decade since MacOS started including forms and markups in their default PDF app (Preview) there still isn't a sane PDF editor for Windows? Chrome and Firefox's PDF viewers don't have editing, Edge has editing and forms but bonkers window management (sometimes PDFs open with Edge but not in an Edge window). Adobe Reader DC still tries to ship with malware, and is license-restricted. What gives?

My recollection is that you need a license to PDF patents from Adobe to implement those things, and Apple is somehow grandfathered themselves into those licenses via NeXT.

(But upon writing that I'm not sure where I got that impression from, and I can't find a citation for it right now, so treat the claim with skepticism.)

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#48

Post by rectang »

emilsedgh wrote: post #29

PDFJS is fantastic. But PDFJS folks, how can you do such a subpar job at documentation? There is really no documentation available on pdfjs. Or a proper changelog. Like in this article they talk about JS execution in pdfjs. And how they have a solution called quickjs. _no_ documentation whatsoever about how to use it. This has been their documentation for years: https://mozilla.github.io/pdf.js/api/ Had I created som…

I recently had to implement a custom PDF viewer using PDF.js. It took a loooong time, because PDF.js is so confusing to work with. We went way over what we thought was a conservative time estimate. :(

It's not just a matter of documentation, but API design. Beyond the bare minimum functionality, you'll need bits and pieces of semi-public API.

For example, if you want to use the "text layer" (for selectable text) you'll need a CSS file which is inside the `web/` directory. But what's in `web/` is incomplete and not officially supported.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#49

Post by roca »

tjoff wrote: post #37
jessaustin wrote: post #4

Earlier quoted context omitted.

It would be possible to implement telemetry that would answer these questions in mostly unobjectionable fashion, but without more information one can see how this could be described as "scary". I certainly hope that forms aren't just being sent back home to Mozilla as-is. However, a monthly ping with statistics like "out of between 50 and 200 documents, between 10 and 50 of them used javascript" wouldn't harm anythin…

It would be possible to figure this out without any sort of telemetry at all. It really feels like a forced way to try and shoe-horn something good to say about telemetry when it is something everyone that deals with PDFs have known since forever. And if that is the best they have to show for it ...

How would you figure this out without telemetry?

A Web crawl could tell you how many PDF documents on the Web use forms, but it won't tell you often your users encounter those documents --- many documents aren't on the public Web, and some documents will be encountered far more often than others.

Re: Implementing form filling and accessibility in the Firefox PDF viewer

#50

Post by jeroenhd »

InitialLastName wrote: post #10
gsliepen wrote: post #2

> Thanks to our Telemetry, we discovered that many forms contain and use embedded JavaScript code (yes, that’s a thing!). There are two disturbing things in that sentence. At least the JavaScript I can see a reason for, it can check whether your input is correct and maybe autofill or things like that, and should of course be sandboxed. The telemetry part is more scary.

> The telemetry part is more scary. There's a nice big section in the Firefox settings called "Firefox Data Collection and Use" that has some fairly fine-grained options for what data you feed back to Firefox. I have all of mine unchecked, but I could imagine that if I were more community-minded, or if I were interested in actively contributing to FF's development day-to-day (for example running on nightly builds) I…

> that has some fairly fine-grained options for what data you feed back to Firefox

I looked into these settings but I can only find 4 checkboxes. Which of the four checkboxes would this telemetry fall under? Is this a study, the result of crash report logging, or is it "data about your interactions with Firefox [..] (such as number of open tabs and windows; number of webpages visited; number and type of installed Firefox Add-ons; and session length) and Firefox features offered by Mozilla or our partners (such as interaction with Firefox search features and search partner referrals)"

I know Firefox collects some technical tracking, but there is no up to date overview of what tracking is actually done. Is there a list of parameters tracked like Microsoft published [1] after the outcry about their terrible tracking? The privacy policy is vague and the documentation for developers [2] contains phrases such as "opaque prio-specific payload. Like { a: , b: }" which isn't exactly useful.

[1]: https://docs.microsoft.com/en-us/windows/privacy/required-wi...

[2]: https://firefox-source-docs.mozilla.org/toolkit/components/t...

Post reply on HN