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

71–79 of 79 posts

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

#71

Post by denton-scratch »

I have a learned aversion to PDF features such as forms. It's partly because HTML already has pretty good forms; and partly because of the long history of gross PDF security failures by Adobe.

I think a PDF viewer (I prefer "reader", because that's what Adobe called their free product) is for viewing PDFs. The point of PDF, to my mind, was that you got a much higher level of control of typography and design than you could get with HTML. So designers and marketers liked it. I have never bought into interactive PDFs.

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

#72

Post by denton-scratch »

fzzzy wrote: post #15

Remember when Mozilla management promised that they were going to kill pdf.js (why?) and replace it with the chrome pdf viewer, then wasted a few years not pulling it off? Good times.

Mozilla management have never been up to the job; clearly their pay needs to grow drastically, to attract better talent. /s

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

#73

Post by jeroenhd »

Jap2-0 wrote: post #62
jeroenhd wrote: post #50

Earlier quoted context omitted.

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

Disclosure: I don't have any relation to Mozilla (so some of this could be wrong), and about half of it I discovered after reading this comment. I do run Firefox Nightly, and follow Firefox development somewhat. I don't see the same screen you do (perhaps something to do with telemetry being force-enabled in nightly?) so this is based off of what you wrote: > Is this a study... Studies are generally minor tweaks in u…

The quote is from Mozilla's own page explaining telemetry, not from the settings screen. The settings are much shorter.

about:telemetry didn't work on my phone (although the screenshots and videos I could find on it seem to indicate that it's just names and raw values, not human-readable descriptions), but it did contain a link to https://probes.telemetry.mozilla.org/ and the newer https://dictionary.telemetry.mozilla.org/ that seem to contain an overview of telemetry data collected.

I don't see anything on there about PDFs and Javascript, so I'm guessing there's another telemetry endpoint out there that I'm not seeing. Maybe the PDF renderer has a separate telemetry system, I don't know. Seeing the amount of (IMO useless) data Mozilla collects, I'll be opting out from telemetry from now on anyway.

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

#74

Post by tjoff »

roca wrote: post #49
tjoff wrote: post #37

Earlier quoted context omitted.

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.

The vast majority of questions like that are quite obvious.

Now what you might miss is that in some country where special circumstances led to an unusual high use of a certain feature.

But this is not that case.

More importantly, even with telemetry. Is the JavaScript adding something or is it solely used for tracking? Is it appreciated by the users?

Maybe 80% of input validation is so broken that they only serve to block legitimate input and waste cpu-cycles.

More than telemetry you need common sense. It is not apparent how the telemetry influenced this in any way.

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

#75

Post by SigmundA »

muizelaar wrote: post #39
alacritas0 wrote: post #20

It's impressive how slowly progress has been made on the firefox pdf viewer. They can't print out pages which aren't blurry from the viewer even though they've had 8 years notice: https://bugzilla.mozilla.org/show_bug.cgi?id=811002

That bug is closed. What PDF and platform do you see blurriness on?

https://github.com/mozilla/pdf.js/issues/2750

It's because pdf.js does not print vector and instead is just printing canvas bitmaps. If they ever get the SVG backend working its will finally have good print quality without trying to get OOM doing measly 300 dpi canvas.

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

#76

Post by seanw444 »

mdiesel wrote: post #25
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?

I use PDF XChange Editor, and convinced my company it was worth it to pay for it (which it is). Aside from editing capabilities and everything else you'd want, it opens and searches large files far quicker than anything else I tried. On mobile, I use MuPDF but its limited on features and I use because it's quick.

Granted, MuPDF is intended to not have a ton of features. Just the essentials.

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

#77

Post by saagarjha »

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…

Yeah, it’s a strange choice considering they ask people to not use their viewer unmodified…

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

#78

Post by zinekeller »

marcellus23 wrote: post #52
zinekeller wrote: post #27

Earlier quoted context omitted.

Actual PDF rotate. In other news, that's precisely why I'm weary to open PDFs in (edit: recent versions of) macOS because it autosaves, and I need to have a bit-perfect copy of said PDF. I mean, I open it in Firefox or Chrome, and this is just a problem that is specific to my circumstance, but it still bugs me.

I think there’s an option in System Preferences to disable auto saving

That's if I do own my own Mac, but this is in situations like if I'm stuck in the marketing division and needed to view a file immediately.

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

#79

Post by fzzzy »

denton-scratch wrote: post #72
fzzzy wrote: post #15

Remember when Mozilla management promised that they were going to kill pdf.js (why?) and replace it with the chrome pdf viewer, then wasted a few years not pulling it off? Good times.

Mozilla management have never been up to the job; clearly their pay needs to grow drastically, to attract better talent. /s

heheheheheheh
Post reply on HN