[HN Gopher] Implementing form filling and accessibility in the F...
___________________________________________________________________
Implementing form filling and accessibility in the Firefox PDF
viewer
Author : xojoc
Score : 89 points
Date : 2021-10-15 18:06 UTC (4 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| InitialLastName wrote:
| 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?
| tpmx wrote:
| Apple did it because they were the underdog 15-20 years ago.
| Microsoft doesn't give a shit. There's no realistic market
| opportunity for a small third party to get a sizeable amount of
| revenue either, with Adobe looming.
|
| I kinda miss the early 90s when we actually had competing
| software "houses" with some financial muscle.
| motform wrote:
| 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.
| tpmx wrote:
| 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.
| zinekeller wrote:
| 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?).
| tpmx wrote:
| So, not really the wrong answer for the past 12 years or
| so, then.
| sudosysgen wrote:
| Okular works.
| evmar wrote:
| 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.)
| kuschku wrote:
| I just use KDE Okular on windows, it's available in the
| microsoft store.
| mdiesel wrote:
| 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.
| InitialLastName wrote:
| I've always been sketched out by PDF XChange Editor (not sure
| if it's the name, the developer's name, or the model) but
| it's interesting to hear that it's legit. Will have a look!
| fzzzy wrote:
| 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.
| jfk13 wrote:
| Sometimes plans don't work out (and/or circumstances change),
| and changing them is the sensible thing to do.
|
| (I don't know details of this specific case, and whether/why
| the plans and decisions made sense at any given time.)
| zinekeller wrote:
| I'll copy out this comment of mine in response to an analogous
| question:
|
| > 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 _(the name of the project)_ when Adobe have
| announced that it will retire Flash.
| gsliepen wrote:
| > 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.
| arbitrage wrote:
| What I find disturbing is that you are complaining about the
| included javascript in forms at this late a date. Where have
| you been for like the last fifteen years?
| rudian wrote:
| Fifteen years is a long time. I'm sure some HN users weren't
| even born yet.
|
| Not everyone needs to care about everything all the time. I
| would complain about JS in PDF too, but I don't have a voice
| anyway.
| djbusby wrote:
| Scary and also helpful. Over reaching telemetry bad. But
| pragmatic, anonymous, usage metrics? Maybe worked this time.
| jessaustin wrote:
| 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 anything. They
| could even add a random error to the statistics...
| ocdtrekkie wrote:
| I often do not have a problem with the information telemetry
| collects: I take issue with the entitlement to it a new breed
| of awful app developers have. They think they have the right
| to use my device for information collection without my
| permission.
|
| If Firefox occasionally showed me a report on some metrics it
| collected and asked me if I was okay sending it to Mozilla,
| I'd probably be fine with it. However, the choice to take it
| without my consent will always be opposed.
| InitialLastName wrote:
| Do they do that? It's been a long time since I installed
| Firefox, but as far as I can tell there are very visible
| settings for controlling the telemetry that they collect.
| ocdtrekkie wrote:
| There are settings, however, they are enabled by default
| to silently send telemetry, and they also implement new
| ways of collecting telemetry, with new settings to opt
| out of it, on an "every few months" basis. So it's a
| constant battle of monitoring what behavior they're up to
| and turning it off.
| tjoff wrote:
| 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 ...
| roca wrote:
| 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.
| InitialLastName wrote:
| > 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 would activate those.
|
| FWIW, I do explicitly allow telemetry for the applications I
| buy licenses for and use for my work; it's in my best interest
| for those programs to be improved as efficiently as possible
| (and to have my use patterns be part of the corpus used to
| prioritize those improvements), and it makes it easier for me
| to report issues.
| jeroenhd wrote:
| > 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: <base64 string>, b: <base64 string> }" 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...
| zinekeller wrote:
| Also, unless you dismiss it, there's a clear button to read
| to read their privacy policy and set telemetry (unless you're
| using the nightly-weekly builds, in this case they state in
| no ambiguous terms that you cannot disable it).
| emilsedgh wrote:
| 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 something as complex and magnificent as pdfjs I
| would've documented _the hell_ out of it.
|
| I get that pdfjs usage in normal web is not their priority and
| what they care about is the Firefox pdf viewer but I'm sure they
| would've had a much better contribution rate had they done better
| api docs.
| gervwyk wrote:
| 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)
| gervwyk wrote:
| Sorry I confused pdfJs for jsPdf.
|
| Perhaps the next step is to build a Lowdefy block that uses
| pdfJs to render pdfs :)
| rectang wrote:
| 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.
| alacritas0 wrote:
| 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
| muizelaar wrote:
| That bug is closed. What PDF and platform do you see blurriness
| on?
| fguerraz wrote:
| I wonder when Mozilla is going to start to include ads in their
| pdf renderer.
|
| I mean it wouldn't really be "ads", more like suggested extra
| pages provided by trusted partners...
| function_seven wrote:
| They could really add value by using AI to detect certain PDF
| forms. If the form you're filling appears to be a tax return,
| then a Helpful Message from a Trusted Partner would appear
| ("TurboTax users average $300 larger refunds").
|
| Residential mortgage application? "Shop Rates and Save"
| BitwiseFool wrote:
| To this day, I do not understand why it is practically impossible
| to simply rotate a PDF and _save it_ in its rotated form without
| downloading some additional PDF application.
|
| Edit: On Windows. I envy Preview in MacOS
| marcellus23 wrote:
| Might want to specify the platform. on macOS that's like 2
| clicks in Preview.app.
| rudian wrote:
| It's a single key shortcut. The document is then auto saved.
|
| Preview.app is king.
| michaelmrose wrote:
| 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?
| zinekeller wrote:
| 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.
| hollander wrote:
| You may need to save it, but you can rotate just one page
| in Preview and keep the rest in its original position. I
| also like that you can click the title in Preview, edit it,
| change the location, without having to close the document.
| c0nsumer wrote:
| 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...
| muizelaar wrote:
| I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1736108
| for that case.
| c0nsumer wrote:
| Well, thank you!
| jiripospisil wrote:
| I'm glad PDF.js' development continues. I completely missed that
| they have abandoned the plan to move to PDFium
| (https://wiki.mozilla.org/Mortar_Project).
| zinekeller wrote:
| 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.)
| muizelaar wrote:
| 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 ---------------------------
| -----------------------------------------------------
| Total 433 174525 13881
| 17175 143469 ------------------------------------
| --------------------------------------------
| zinekeller wrote:
| 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).
| glandium wrote:
| There is no wasm in the version built-into Firefox.
___________________________________________________________________
(page generated 2021-10-15 23:00 UTC)