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

51–60 of 79 posts

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

#51

Post by iapark »

rectang wrote: post #48
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'…

I wish there were better wrappers for it too. One of the projects I'm still quite proud of that I made as a student was a react wrapper around PDF.js used here https://boardbook.kent.edu/ (though since they no longer seem to be using it I guess it will probably go dead at some point), but the fact there wasn't really a good open source one and as you say the docs were pretty lacking. My favorite discovery was that the performance was much worse unless I registered a particular scroll listener. It's been years now so I only vaguely remember, but I think registering a listener for `wheel` would cause scroll events to be treated as blocking and this made the whole scrolling experience less janky.

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

#52

Post by marcellus23 »

zinekeller wrote: post #27
michaelmrose wrote: post #23

Earlier quoted context omitted.

Is it actually rotated or does it just remember that that document is supposed to be rotated? In other words if you emailed it to me would it still be rotated when I opened it?

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

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

#53

Post by blondin »

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.

> How would you figure this out without telemetry?

the way the world has done it forever... a survey?

it is concerning. if Firefox is doing it, they are all doing it. i am not going to be opening PDFs in browsers.

this is ridiculous.

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

#54

Post by roca »

blondin wrote: post #53
roca wrote: post #49

Earlier quoted context omitted.

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.

> How would you figure this out without telemetry? the way the world has done it forever... a survey? it is concerning. if Firefox is doing it, they are all doing it. i am not going to be opening PDFs in browsers. this is ridiculous.

A survey for this is going to be useless for getting unbiased data.

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

#55

Post by charcircuit »

blondin wrote: post #53
roca wrote: post #49

Earlier quoted context omitted.

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.

> How would you figure this out without telemetry? the way the world has done it forever... a survey? it is concerning. if Firefox is doing it, they are all doing it. i am not going to be opening PDFs in browsers. this is ridiculous.

A survey would be heavily biased. Telemetry will have much less bias (there is still some since people who disable telemetry have their usage ignored)

With better data you can make improvements that help more actual users instead of just focusing on what vocal minorities think.

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

#56

Post by mistrial9 »

tpmx wrote: post #33
motform wrote: post #28

Earlier quoted context omitted.

preview.app has been around since NextSTEP, which used display postscript for its windowing engine. Having a first-class pdf reader falls out pretty naturally.

Sure. Spending money on implementing okayish PDF forms support.. I'm going to out on a limb here and say that it wasn't done out a position of strength.

wild guess here -- MacOS had given way to MacOSX, but commercial printing and publication workflows had not. Windows via market mechanisms (plus assorted dirty tricks), had a lot of installed desktops by that time in the print world, with a much smaller set of the artsy people and some others still championing Macs. When MacOSX got stable after the first few releases, the NeXTstep postscript handlers were there, and Apple wanted to compete to get users to buy new Macintosh hardware for print. Anything and everything to attract print people was definitely included.

Forms were appealing to some businesses and I dont have insights on that part of it, other than noting that odd media formats and bolt-on web'by things were being added to PDF at the time, and as for common forms solutions, apparently fifteen years later its still not settled.

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

#57

Post by not2b »

tpmx wrote: post #12
zinekeller wrote: post #11

Earlier quoted context omitted.

Wrong answer, at least for a time. Microsoft was actually sued by Adobe over the PDF implementation with Office 2007 (before it was standardised in ISO, that was circa 2008-9 if I remember correctly). That's also the reason that XPS (the weird Microsoft format, not Dell laptops) exists. Nowadays though, I don't really know since Microsoft has successfully overturned that case (probably because of Adobe being Adobe?).

So, not really the wrong answer for the past 12 years or so, then.

The number of years depends on when the various patents expire. Does anyone know?

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

#58

Post by spankalee »

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…

This reminds me that I should finish off my event based on PDF.js with the goal of just being able to drop an easily customizable viewer into any page:

https://github.com/justinfagnani/pdf-viewer-element

On the docs front, I couldn't agree more. It's tough to use.

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

#59

Post by jd3 »

evmar wrote: post #47
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.)

ignoring the "thoughts on flash"[0] letter, the apple adobe relationship goes back to at least the apple LaserWriter[1], so that would definitely make sense

the Quartz compositor itself has "use[d] pdf internally"[2][3] ever since the initial launch of Mac OS X

> By the time OS X came out, these were less the kind of features that "the next great personal computer operating system" should have, and more the kind that they all had. What was new included how Quartz, the engine for OS X's "killer graphics," was based on PDF.

> "What does that mean?" asked Jobs. "You know when you go to the web and you see PDF documents? Well, that technology is now at the core of Mac OS X's graphics. So you can image PDFs instantly. So now all applications get this for free."

> It's how, to this day, every Mac app can produce a PDF document without needing a third-party app.[4]

[0]: https://web.archive.org/web/20100531072734/http://www.apple....

[1]: https://en.wikipedia.org/wiki/LaserWriter#Apple's_developmen...

[2]: https://www.youtube.com/watch?v=Ko4V3G4NqII / https://www.youtube.com/watch?v=6-fkYFV7rOY

[3]: https://en.wikipedia.org/wiki/Quartz_(graphics_layer)#Use_of...

[4]: https://appleinsider.com/articles/21/03/24/apple-launched-it...

https://pspdfkit.com/blog/2020/apple-and-pdf-history/

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

#60

Post by twodave »

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 think it's funny that someone added 1 CoffeeScript file to the codebase and didn't write a single comment about it.
Post reply on HN