Native PDF clients have had lots of security holes. In this case having the client written in JS means we can repurpose the battle hardened JS sandbox to also contain PDF exploits.
And here I found it much less bloated than the other free desktop PDF viewers.
I think Mozilla's line of thought here is that PDF documents are widespread in the web, to the point where they are a de facto web document type. So it makes sense for a web browser to support them rather than calling out to a user's desktop program (though I assume you can configure it to do so instead).
There's probably a bit of "our competitors do it, so we have to too" in there as well.
Given that Chrome/Edge also just added the feature, I would point out: All web browsers are using the same library for PDF handling, a feature in pdf.js ends up benefiting a lot of people.
And the reasons for not requiring an outside PDF reader are major: It's yet another likely-to-have-vulnerabilities program people need to install, then update. In most cases, avoiding Adobe programs on your PC is a good way to avoid a lot of vulnerabilities.
A Chromium fork could replace certain components if they so choose. The PDF rendering component would be one of the easier ones to replace.
However, I was able to confirm that Edge uses extension ID mhjfbmdgcfjbbpaeojofohoefgiehjai to render PDF internally[1], same as Chrome, so indeed it's using PDFium.
I like that single-page PDFs stay in the browser. I don’t want to keep them; I just want to see them. Like any other web-page. I want to be able to hit back, or close the tab, and continue on with my day.
And I also like that I can preview long-form PDFs in the browser, before choosing whether to save them and read them “for real.”
Imagine if every time you opened a direct-linked JPEG image in your browser, it treated it as an attachment, downloading it and opening it in your external image-previewer app, rather than rendering it as a synthesized HTML DOM wrapper around the image. Wouldn’t you be annoyed by how cluttered your Downloads directory would get with random files you never actually wanted to save?
Given the amount of PDF exploits over the years and the habit of browsers to automatically invoke your PDF viewer of choice either as a plug-in or call out, they're an easy target.
Having a sandboxed PDF viewer that works 95% of the time is great. For those 5% circumstances where I am actively trying to view a PDF and it won't work in browser, I'll gladly go through the minimal effort to open it in an external viewer.
It was once an add-on, and it was once disableable. It may still be disableable, but I'm sure there's some strange procedure you have to go through to do it.
The real problem here is that, 20+ years on, printing to PDF is still a totally natural and easy-to-understand metaphor for a normal office desktop user; but producing HTML for the browser is still impossible for them.
If we simply had print-to-HTML functionality which resulted in a document identical to what you view onscreen while editing, PDF could die the death it deserves.
But HTML+CSS somehow manages to suck just as much for common usage, so it persists.
I wish epub would catch on for more than books. An epub is just HTML and CSS in a zip file, and a large part of the world population has a device than can load it and present it cleanly.
> Is there something hard about fillable forms on PDF?
In the sense of a “form” just being lines on paper that you can arbitrarily add some text to — no, that’s easy.
Likewise, in the sense of a “form” being some defined input regions that accept your keystrokes and turn them into new text DOM nodes in the PDF itself — easy enough. Though, unlike HTML, there’s no concept of an <input> tag that just has the semantics of accepting keystrokes and turning them into (persisted) input; instead, this all has to be done through scripting [i.e. writing event-handlers, or having some PDF authoring software generate them]; and there are several incompatible scripting languages for PDF that get used, some of which are proprietary with no open specification.
But, doing form validation? Or, worse yet, making one of those fancy PDF forms that auto-calculates fields like an Excel spreadsheet? Now you’re getting into the hairy stuff, because IIRC none of the open-standard PDF scripting systems provide these sorts of mechanisms, so these are inherently proprietary things.
And when I say “proprietary”, I mean “like old versions of Word or Photoshop, where each version emitted its own in-memory data-structures to disk without formal serialization; and it was the job of authors of future versions to write importers to deserialize whatever format resulted.”
I posted a link (above) to the app I built to solve that problem.
The vast majority of form is indeed not « ready » for input, requiring users to go through hoops to fill them. And that work is done again by the next person.
I wasn't referring to any problem. Again, all those PDFs I wrote about are intended for reading only; no filling in, signing or other form of interaction other than reading letters that form words on a page is involved in any way, and that is entirely fine and how it should be, so both the PDF itself and a PDF reader that has no form-filling functionality would be entirely fit for purpose (notice the word "reader").
Yes! PDF forms are amazingly complex. Text in PDF is very complex and the forms themselves are a kind of templated vector graphics. Multiply this by all the weird and corrupt PDF forms out there which Acrobat support and you have a challenging task.
What's the problem with the Poppler-based ones? I've been producing (with LaTeX) and consuming (with Poppler/Okular) PDFs for a decade and never once have I had to worry about anything related to the format (including tracking).
Poppler looks great! But, I _just_ learned about it and I don't think that the majority of population, say, outside of HN knows about its existence, so it's good to have a fairly mainstream alternative available.
OK, Firefox is, sadly, far from being a mainstream browser nowadays, but still I suspect it has a larger user base than Poppler.
And here I was thinking we were living in the future when I could print out a pdf, fill out the fields with a pencil, take a picture of it, then email it to myself, change the file type back to pdf, and send it to whomever requested it...
I think it was William Gibson who once stated something like, "The future is already here, it is simply unequally distributed...in that, some people just fill out PDF forms, while others have to print it out, fill it out with a pencil...etc...." Ok, maybe i'm remembering that quote inaccurately. ;-)
Search in PDF is broken since this update. I must go through the whole document for Firefox to load it up and being able to search in it. Couldn't find a similar issue on Bugzilla. Anyone having the same problem?
I looked into coding PDFs once. Then I closed my MacBook (Pro) and went for a long walk into the ocean. I think I almost got to America, but then I turned and swam back again. Turnd out I had just fallen asleep and had a nightmare. I was actually just working with regular text files, and everything was fine.
I had to handle action buttons for a PDF once. I swam out from America a long long ways before turning back. Might have spotted you middle of the ocean.
My favourite PDF fact is that it doesn't have to start at the beginning or end at the end of a file. Any sea of bytes that contains a PDF file is an acceptable PDF file...
Did anyone try to pluck out PDFs from /dev/urandom? How about from radiotelescope feed? Maybe the first evidence of extraterrestrial life will be some poor alien's tax form?
Actually I'd argue the example you provided is normal, as long as you authorise a particular encoding where every number n you're looking for is encoded as a string of n zeros.
It's then trivial to see that every number you can think of is encoded in there, and therefore any data, piece of music or movie that ever existed.
(I'm not sure we're allowed to fiddle with the encoding, but since we allow ourselves to represent a piece of music into a number, we're already talking about encoding anyway, so it doesn't seem like cheating to me...)
Normality of a number is with respect to number bases, so your trick with encoding is invalid. Otherwise, every computable number could be considered normal - take an algorithm for generating of it, supply a random string (this is the encoding), disregard the random string, and you have a perfectly valid normal representation of your number. So it is cheating.
Normal in this sense means that all the frequency of all digits approaches a uniform distribution as the length of the sample increases towards infinity. Basically if we could see "all of" π and count all the 0s, 1s 2s, 3s, &c to 9 all the counts would be equal.
That on its own can't be right, because 0.12345678901234.....
According to wikipédia, you gave a definition for "simply normal", and for normal numbers the distribution of any sequence of digits is uniform. So 00, 01, ..., 99 each occur uniformally too.
I mean, the answer is trivially zero, there exists a PDF-like structure somewhere in Pi, and the offset of that doesn't have to be zero, it can start or end anywhere. So the range [0, N] is a valid PDF.
your example fails to satisfy the invariant. 11 is less than infinity.
you're just pasting random python snippits at me now. It's time to move on.
again, just to summarize: PDF files do not have to be zero aligned, and they do not have to be end aligned. Therefore the answer to the question "what is the first segment of Pi that is a valid PDF file" is trivially (0,infinity). That is a correct statement. The non-greedy (in the regex sense) answer to that question will be different, however.
Why is this so hard? If the tuple (0,10) represents the range of a valid pdf, then the next tuple (0,11) is also a valid pdf. Or any after it up to and including (0,infinity).
Note the word "next", implying that (0,10) sorts before (0,11); you even say it yourself "11 is less than infinity". Where I'm from "first" and "less" are related (the first element in a unique sorted list is defined to be less than all other elements). So if there is any valid pdf in pi that can be identified by the range tuple (0,N), then the first valid pdf must occur before N -> infinity. Therefore (0,infinity) can never be the first valid pdf, even though it may be a valid pdf.
Maybe a picture would help:
Potential pdf file ranges in pi: [(0,0),(0,1),(0,2),(0,3),(0,4),...,(0,N-1),(0,N),(0,N+1),(0,N+2),...,(0,infinity)]
Is it a valid pdf? no no no no no (no) no yes yes yes (yes) yes
Which one is first? ^^^
I thought linking to a python script that shows the order comparison of a tuple (0,N) as less than the tuple (0,N+1) would clearly demonstrate this, but it appears to have failed to communicate that to you. We don't need non-greedy regex rules to do a less than comparison.
I'm not sure that's necessarily true. It is true (at least with a non-constructive proof) that if you pick a 'random' real number then it contains all possible PDFs with probability one ( or that the set of numbers for which this is not true has lebesgue measure zero). But I'm not sure it's known that pi has this property.
No, all strings theoretically exist in 𝛑 given enough digits, so longer strings don't reduce probability of existence, they just mean that it will take more digits to find them.
On the other hand, this allows for some incredible polyglot files, like some of the tricks with PoC||GtfO issues where the file is a readable PDF but also a game cartridge and also a zip file with the proof-of-concept code in the issue. And the front cover has the MD5 hash of the whole file printed on it... but that's another trick entirely!
I worked for PDFTron on their WebViewer product earlier this year, and primarily spent time implementing this feature in JS. Understanding the spec on this was tricky, because standard PDF viewers need to be able to uncompress the stuff you jam in there. It kind of blew my mind that you can literally jam any arbitrary file into a PDF.
My favorite pdf fact is that the security flags for things like copy protection and passwords are on the viewer to implement so you can just turn them off and all the security is gone
Seems to be a reasonable analogy with trespass, where you are violating the law when you cross an invisible line. The need for marking the line varies considerably.
And even places with strong roaming rights tend place limits on well marked land.
So what if you open it in a postscript viewer instead of a PDF viewer? Because they are compatible formats except for some edge cases like security flags.
This is not entirely true, you can encrypt PDFs [1] since v1.3 of the spec but the cypher is often so weak (RC4 until v1.6) they can be bruteforced in reasonable amounts of time.
You can encrypt them to completely prevent them from being opened. But cgb223 wasn't talking about that, cgb223 was talking about the ability to open them but not copy text, or not print.
You can make the text uncopyable by using non-standard font indexing. The reader will be able to copy the text but it will be gobbly-gook. It forces the user to OCR the PDF or reverse the font mapping.
Debian actually goes out of their way to patch those checks out in their PDF-related packages as part of their stance against DRM, like this example with "pdftk":
Some readers won't need a header at all, I think. Near the end (usually!) of the file there's an index of objects (page data etc.) with byte offsets, which can point to anywhere in the file.
I never understood that Google security blog post on how they could make 2 different PDFs with different content have the same SHA but now that you mention you can stuff bytes in a file unrelated to the PDF, it makes sense...
What's your favorite PDF feature that causes a brain meltdown?
I've read a few comments on HN how PDF is, well, not developer-friendly. If people are interested in providing some more examples here, I'd be curious to know!
That’s correct - I worked with MS team that documented old formats, and they said that sometimes they don’t have people left who knew what specific struct was intended for - although that was mostly for people PowerPoint and Visio, excel and word was better documented
You don't remember correctly. Word's docx format is far more intelligent than openoffice ODT, despite propaganda to the contrary. With one exception: word's zip files don't have a convenient magic header. The way it works with ODT, and a bunch of other formats is that you put an uncompressed identifier file (`mimetype`) as the first entry inside your zipfile. At byte 30 (of your zipfile) you then get `mimetype$THE_MIMEMETYPE`. This is a nice trick and works for any zip-based format. Sadly, docx does not do that so you have to go by file extension or look at (more of) the contents of the zipfile.
IIRC the original doc (and xls) formats were unwieldy mainly because of performance requirements. In order to save and load fast they were basically a bunch of binary dumped structs.
and if they hadn't waited so long to update to a sane file format no one would complain but they waited until 2007 to fix the format long after the dos era memory excuse had long ceased to be an issue. even then they only did it to allow them to shoe horn their format in as the iso standard after one was already selected bribing there way through the process.
Ms office files prior to office 2007 were mostly memory dumps of specific components, wrapped into composite files aka OLE2 storage - their content varied depending on office versions and often locale
That's great because it creates client expectations regarding what my PDF application should support. Implementing the spec is not good enough, you have to do what PDFium or Adobe do.
In the early 2000 I coded a PDF library for an industrial printer suite. (Print, proof, impositions)
I personally think the structural PDF format is a really great format. It's entirely ASCII-based, a pure text format, yet it can embed arbitrary binary data and compress that data. The actual structure is simple and support just enough functionality, like a tree of object, dictionaries and arrays, unicode strings, date formats, etc.
I think if you limit yourself to pure structural PDF woulde have been a great format to standardize upon, much better than JSON or XML. It';s richer than JSON, simpler and saner than XML. Again, it's top-notch ability to embed binary is great. It has other great characteristics, for example you can update anything just by appending.
The ugly bits are in the "semantic" PDF: the page descriptions, media, etc. Even then, the early version of PDF were nice, mainly just simplified Postscript.
I'm of a similar opinion but I'll say the format is quite good, but the many and varied implementations are often not.
A common case is clients who use utilities that generate single customer documents then merge them into a bigger file for bulk print and mail (bills and statements, not identical copy). Without fail that results in thousands of similar but different subset fonts whereupon most printers I've encountered eventually fail due to memory issues.
Typically this leads to a discussion about "I can open it on my computer fine" and bending over backwards to find a workaround. Merging and consolidating these fonts doesn't seem to be a simple task, although some tools claim to work some of the time.
Something that scopes object resources for disposal could be nice in the PDF spec (maybe it exists), but something like a LRU caching mechanism on the printer would potentially resolve this too.
This is also my list. Except for the forms, that's one I don't have to deal with.
My other one is the use of multiple subset fonts that are actually the same font with a different subset of glyphs that you want to merge back together.
Being able to do SQL queries to remote servers, upload form contents directly to a server, embedded 3D models and being able to have a fully featured page embedded Tetris game due to support for JS.
Having said that (and worked on a commercial PDF library), despite all the cruft that came with age, it's a well built format that survived the test of time with good reasons.
I worked on a Pdf with inbuilt tracking solution that updated the form layout using ActionScript based on the workflow status and the role of the user (ie the line manager had a different group of fields in the form to complete like their signature while viewing what the initial requestor had entered) Lots of callbacks to the server saving in progress data and updating the status of who had the form, who was next based on department and emailing it to that person if it passed validation.
An initial fun discovery was that you could force the form to download and replace itself with the latest version even if they had just opened some old file they had on their pc.
"Identical" PDFs are not necessarily byte-identical; you can't just check equivalence through checksums. (AFAIK, it's been a while, feel free to correct) I don't remember a good way to normalize/disambiguate, at least I never attacked the problem long enough to have learned.
EDIT: oh yeah, I'm pretty sure it contains Mail, just like Zawinski said
I think one of the biggest pain points that developers hit that hasn't been mentioned here is content extraction.
A lot of the time developers want access to the text inside PDFs. Unlike HTML or formats like MS Word (XML or old binary format) getting "text" isn't really possible.
Most "document" formats have the concept of words or strings: a set of characters separated by whitespace. PDF isn't a "document" format in that sense - it's a page description language. Instead of strings of text you have character glyphs positioned at a particular location.
If you want to "read" the text, you have to work out the orientation (which can change throughout the page - think of table header alignment), and use some kind of heuristic to guess the word spacing based on the font and character spacing.
There's also this whole thing with clipping, where some text can be hidden behind other objects (or off page) so you have to try to deal with that.
There's lots of libraries that try to do this for you, but there are lots because none get it right 100% of the time...
OK, they added various ways of data compression, but PDF is, basically, a text-based format.
As far as I know, any PDF can be losslessly converted to an equivalent PDF that can be edited in any text editor, even Notepad. And yes, you could fill in the forms there, too (if you were stubborn enough)
It sounds like you either know a lot more than me or a lot less than me. The PDFs I've dealt with don't store text as strings, they store it as individual characters. This left me having to write a heuristic based algorithm to group the characters into words, words into lines, lines into paragraphs, paragraphs into columns.
Again, as far as I know, there are no heuristics good enough to get that right for all values of PDF.
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...
Could it be “compacting” the fonts? So if U+0000 to U+0007F aren’t used at all, remove those glyphs and set U+0000’s glyph to be what was U+0080? Yes, I know NULL doesn’t have a glyph, but I hope that gets the idea across.
Where did I say PDFs have to be in text format? I said every PDF has an equivalent text-only representation. The format, like postscript and eps started as text-only. Compression, making the files binary was added as an afterthought, to make files smaller (much smaller). If it were binary from the start, its designers would not have made the table of contents at the end waste bytes by writing offsets in ascii.
Look at Chapter 3, Syntax. The code is all text based. We are not talking about the visible characters in a PDF viewer, but the code of the PDF file itself.
Going by your original premise though, just so you know the reference does indeed have examples of text as strings e.g.
BT
/F13 12 Tf
288 720 Td
(ABC) Tj
ET
This can be extended to include spaces so you can essentially mark up entire lines of text at one time. What it can't do is cohesive paragraphs and flow/wrap, you need to use the relative positions to work out what text is in one block (and usually I'd defer to something like pdftotext for simple cases).
Laying out individual characters is common though. It's probably due to kerning concerns.
That’s news to me and Bluebeam’s PDF search feature! It turns out you can make PDFs (This usually happens with architectural drawings) that are comprised purely of images that are not searchable, and therefore you are wrong.
I silently thank every architect that provides searchable PDFs, it makes my job way easier
GP is right. The code that makes up a PDF is text-based. Those images can be encoded in the PDF file using the ASCIIHexDecode filter, i.e. as editable ASCII text code.
Only the "binary" bits like fonts and bitmap images would need to be hex (and then only so Notepad doesn't mangle them). Everything else in an uncompressed PDF is already text. Go here and download the PDF spec.: https://www.adobe.com/devnet/pdf/pdf_reference.html
Look at Chapter 3, Syntax (and the rest of it, really).
I literally have scripts that use bash and sed, or Python, to modify PDFs by editing the text code. Doing it in Notepad is possible but tricky, as there's a table of object byte offsets near the end that it's easy to mess up by inserting a character.
GP uses the phrases "losslessly convert to text" and "fill in the forms". I think you've misunderstood them, they're clearly talking about the display text, and not the code that comprises it.
I thought I found a nifty trick by using OpenOffice to create a form with a pre-filled value. I decoded the PDF using pdktk or one of the free tools, and then modified the value. Nope, that caused some kind of cascading/checksum error.
Ended up just making the app generate HTML before calling wkhtmltopdf.
The PDF spec is insane! But like all things what you get out of Word/OpenOffice is 100x more complex than if you wrote it yourself, which is indeed doable.
It's really not that difficult if you read and understand the PDF specification. As a learning exercise, I created a simple PDF generator library that creates ASCII PDF documents (you can open them in Notepad) and includes comments about what each drawing instruction does.
I am actually interested in doing pure JS pdf processing. All of the web interfaces for PDF processing are server side — which means it’s tough to process large files. The dream is a purely JavaScript solution that never leaves the local computer. I’ve got a few client-side success stories that do fairly significant image generation through the canvas. So far PDF seems reasonably manageable through manipulating the text, but it’s not the best format.
> The dream is a purely JavaScript solution that never leaves the local computer.
Mozilla's pdfjs[1] project is a pure HTML/JavaScript solution for PDF rendering. This is the same code that ships in Firefox browser as well. This is standalone, AFAIK, it doesn't talk to a mothership.
Years ago, I worked on a project that required generating PDF invoices. Used the FPDF library and I was shocked how small the files are (including a properly sized logo) when generated compared to most other PDFs 'rendered' from word or print processors.
I just had to do tech support for someone whose 3 MB PowerPoint of text and some shapes became a 70 MB PDF that they couldn’t send through email anymore :/
The last time i wanted to do that, i noped the fuck out, generated latex, and pdflatex-ed the thing, to get the pdf (we're talking generic reports, text, table, graph, email to customer on a schedule).
I’d be surprised if Adobe has implemented 100% of it. With a format this complex, there’s bound to be discrepancies between the spec and the code they have.
Reading PDF files is certainly a nightmare. But you can easily produce a valid and simple pdf file just by printf-ing whatever needs to be printf-ed. There's an ugly header and the rest is essentially your text.
I had a look through the XPS standard and had a similar feeling. I complained to a friend that had been involved in one of the bigger pdf libraries. He then made me compare it to his version of the pdf 2.0 (iirc) standard.
That is truly nightmare material. Especially considering a non-trivial percentage of pdfs circulating are non-conformant and people still expect them to render...
Why is Firefox spending all their money and goodwill on a piece of technology that should be done away with?
PDF is a dork. It's an accessibility nightmare with no obvious advantage over simple ordinary webpages. Somewhere in the comments below, it is mentioned that supporting PDFs is a non-trivial piece of technology. May be! Even steam engines have non-trivial technology under the hood.
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?
There's nothing a PDF can do that a webpage can't. In fact there are a hundred of things that a webpage can do, but a PDF can't. Including, form fields, input fields and seamless form submissions.
Anyone can create a PDF form to capture data and signatures, email it to someone who can then fill it out offline, and then email it back. That's not something easily done with a webpage, and it's not something my mom can do.
PDFs are easy to make and easy to work with. Web pages aren't.
Your work is impressive, and why would anyone want that? Do you envision lawyers putting all their legal contracts into fancy flippy books?
> Do you envision lawyers putting all their legal contracts into fancy flippy books?
Someone will have to solve it for the lawyers in a not so 'fancy consumerish' way. Point is that it is possible to do that, and Firefox shouldn't be solving this problem using an ancient format and a layer of cruft in between.
I think you missed the point of distributing. I’m never going to let you email me your serviceworkers because I can’t forward this document to anyone without relying on you hosting a server / not changing the content.
Oh, I'm all in for email/attachment based distribution. Just not with Firefox sporting it on the web browser where you'd in all certainty require someone to host a server and for you to trust them that no changes have been made to the content.
That was the entire point of my comment at the top.
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.
Yes, maybe generally; but let’s talk about the specific case here — filling of complex PDF forms.
When a PDF that has interactive form fields, calculated auto-populated fields, fields that are enabled/disabled according to the inputs of other fields, etc. — the organization that created it (usually government or education) usually does that because they want you to fill it out using a PDF viewer; save it (which will persist the form inputs “into” the resulting PDF); and then submit the modified PDF file back to them. They want this, because they can use automated backend processes to extract the data from the PDF. They don’t want you to just print out the thing and fill it out. In fact, many such “fillable” PDFs start off in a state with many of their form-fields disabled and voided, such that printing them out in that state would result in a form you can’t really write on!
So, at that point, why didn’t they just make the PDF a web page? They’ve essentially reinvented a web form, but with extra steps. The only benefit a client gets is the ability to edit and save the form offline (but that can be done in a browser, too, with local storage); and furthermore, the ability to treat the resulting filled form as a file, moving it around before you submit it. But the cases where you need that are very niche, compared to the cases where you can just direct employees to your Intranet portal.
The use case you're describing wasn't feasible until about 20 years after PDFs were introduced. Web Storage isn't that old, has only recently become widely deployed, and in a lot of cases is disabled for security concerns.
> In fact, many such “fillable” PDFs start off in a state with many of their form-fields disabled and voided, such that printing them out in that state would result in a form you can’t really write on!
I have never seen this. Do you have an example? Every use if fillable PDFs I have encountered is a use case where submitting a handwritten form is still an option.
> The only benefit a client gets is the ability to edit and save the form offline (but that can be done in a browser, too, with local storage); and furthermore, the ability to treat the resulting filled form as a file, moving it around before you submit it.
I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy.
> But the cases where you need that are very niche, compared to the cases where you can just direct employees to your Intranet portal.
This is not a trivial need; most forms sent as fillable PDFs need to or should be retained for some period after submission. Also, I don't know what "employees" and "Intranet" has to do with anything.
You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork.
> You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork.
My company have to do this for one state government. They required the signature to be written black inked. It is PITA to do since we all have digital signature set up. But nope, this state government required the written signature.
I don't have one on-hand, no. But I've certainly had to fill them out in the past. IIRC an especially-bad one came in the form [heh] of a student-loan application for the college I attended. It was essentially a Hypercard stack in the guise of a PDF.
It sounds like every PDF form you've ever dealt with is what Adobe, in this brochure, calls a "Type 1: Print and Fill" or "Type 2: Fill and Print" form. But Type 3 and Type 4 forms do exist in the wild! (They're not often created any more; most of the ones that exist now are from around a decade or two ago, when Adobe was really pushing this idea.) Creating such forms was basically the point of Acrobat as a software product.
When PDF viewers (e.g. Apple Preview) say they don't support "PDF forms", they're not talking about Type 2 forms. They usually support those just fine. They're talking about Type 3 and Type 4 forms. And more specifically, the ones that use Adobe's proprietary AcroForms data-embedding system, rather than the open-standard XFA data-embedding system.
(I could swear I saw an HN post about the horrors of AcroForms once, but I can't find it now.)
> I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy.
To be clear, that was what I meant by the second qualifier, "as a file." Browsers support persisting the state of the form. Just, not as a file. They persist the state internally, when the form's author does the client-side Javascript work to enable that.
For the use-case where the user wants to stop filling out the form for now (e.g. because they don't have some required information on-hand), and then come back to it to finish it later, in-browser persistence works perfectly well.
Even cleaner, though, is just building a web-form as a wizard, where fields are submitted one-at-a-time, and you can also freely navigate to previously-filled "steps" to change your answers. That doesn't even require JavaScript; just pure 90s HTML-generated-on-the-backend. Most government sites that thought PDF eForms were a good idea, are now falling back to this approach.
> Also, I don't know what "employees" and "Intranet" has to do with anything.
Secure installations. The main use-case for fillable PDFs (as can be seen in Adobe's marketing brochure, where "government" is the core client) is a case where public or cloud solutions just aren't tenable, i.e. in secure government/military/etc. installations, where the workstations are air-gapped from the public Internet. In such a case, PDF forms can still be sent around via a local non-Internet-routable email server, for the workers there to fill in.
Today, this need can be served just as well by setting up a non-Internet-routable web portal for those same workers to use. But back in the 90s and 00s, "Intranet web portals" were a fancy thing only the most forward of IT bigcorps had on offer. They had Intranets, for sure, but they weren't hosting web-apps on them.
So, what did they do instead? Well, Adobe had two main competitors in the "eForm" market:
• Lotus Notes form documents, connecting to a Lotus Domino database server;
• Microsoft Excel sheets that use VBA to data-bind to an accessible Microsoft Access database file sitting on an SMB network share.
None of these "forms" were hand-submittable. They're all little self-contained interactive applica...
1. A webpage form requires a server to be up and running, which requires an IT person to manage it, separate from the dept making the form. PDF forms can be created by a person given the right tools (I think Word does it)
2. IT person + webserver costs have to included in the budget somewhere. Which can be a big problem.
3. The webpage form can fail, and the support for it has to be provided by the IT dept. If the PDF form fails, dept can handle it on its own, and will often accept a filled+scanned print out of the PDF form.
4. Adding to the point above, PDF forms degrade gracefully, If they don't work, or internet doesn't work, or someone is on holiday, you can still print, fill and hand them in person. Webpages can degrade catastrophically where you whole dept grinds to halt while the IT person tries to fix the problem.
Re: all four of your points — see my sibling post. I'm not talking about encapsulated-PostScript "Print and Fill" forms (which do certainly degrade gracefully), or even open-standard PDF "Fill and Print" forms (which degrade gracefully if you don't set them up with a bad default state where there's big "N/A" text over all the disabled fields until you fill in other fields.)
Instead, I'm talking about the PDFs you can basically only load in Acrobat (though, other PDF viewers do try to render them, to varying success) that actually do data-binding to some remote database; do XHRs to submit the form data on success; do "online" onBlur-XHR-esque field validation; generate new output PDFs using scripting, from scratch when you ask them to save/print; etc.
These are applications, not documents. You can't print them. You just use Acrobat as a glorified application host to fill and submit them. (You can press Ctrl+P to get Acrobat to request to the loaded PDF application that it perform some scripted action to generate a print output. This may or may not do anything, depending on how the PDF was created. It usually just pops a "Printing is not implemented for this form" box. It certainly won't work in non-Acrobat PDF viewers.)
When other PDF viewers say they don't support "fillable PDF eForms", these are the things they're talking about. They usually support "Fill and Print" forms just fine, because "Fill and Print" forms are a somewhat-sane format, rather than being a competitor to Lotus Notes.
I understand better what you are saying. I don't think I have ever seen any PDF forms that require an internet connection. The Canadian Visa application forms have inbuilt validation code, that checks the form, and once you upload it, I believe data is extracted into a database.
The benefit of these forms is that the validated form that you submit online is actually printable. Which means that what you see on your screen/paper is pixel by pixel identical to what Canada receives, and therefore _legally_, there is no confusion about what was communicated between Canada and the candidate.
Webforms are not as strongly accepted as such by courts. Because they have to be manipulated further before being printed.
I have read a bunch of your replies, and you are thinking of all the technical reasons why webforms are better than PDF (you are right in that), but PDFs have legal and operational and budgetary advantages, that are more relevant to various organizations.
> It's an accessibility nightmare with no obvious advantage over simple ordinary webpages.
It is easy to criticize something when you don't look back at the historical context through which it emerged. It has plenty of advantages over HTML but they're easy to dismiss if you don't have a use case for them.
> It has plenty of advantages over HTML but they're easy to dismiss if you don't have a use case for them.
Can you discuss some of the advantages? The only advantage that comes to mind is that Apple has built-in support for writing PDFs and that has a lot to do with Adobe rather than PDF being a better candidate.
I work for US Federal courts, I can assure you html isn’t sufficient over PDF’s for court cases. Evidence are filed in pdfs. Documents (PDFs) need to be a historical archive, and the ability to modify would damage the credibility of those documents.
Yeah, but does Firefox need to solve the use-case of a court system? Also, tangentially the solution to guarantee "tamperproof" archiving is in cryptography and that's not a feature of PDF.
No, Firefox doesn’t need to support the use case of a court system. That’s not what GP is saying. All we’re establishing here is that PDF is a useful format, and Firefox is supporting it.
Also, cryptographic signatures do happen to be a feature of PDF.
Now that I read my comment I see the issue with it.
What I meant to say is that Firefox should focus on implementing cryptographic signing over HTML then. And not a PDF viewer on the web--in that, enabling cryptographic signatures isn't tied to the format PDF per se.
PDF's ubiquity is 100% that it printed the same (or close to same) on any postscript compatible printer. It's tech so old many in the industry ignore the reason it existed (and still exists). Every solution beyond PDF has also been either closed source (read Microsoft) or ignored. It's useful, that's why it exists. Yes, it's archaic, yes, it's hard to read for tech people, but for non tech people, it solves an issue that plagues the entire software industry: Standardization.
> Why is Firefox spending all their money and goodwill
I doubt "all" their money goes towards the pdf-reader bit. And tbh, I'd say nobody will really lower their goodwill towards Mozilla because they add features that a lot of people actually need.
“After entering data into these fields you can download the file to have the filled out version saved to your computer.”
What’s the use case? Printing out filled-in forms? But otherwise, who would want the PDF in electronic format? It doesn’t seem like a practical way for users to submit data.
That's my point. Other than printing a nice looking form (which includes faxing), the content of the field data is hard to reuse. Searching PDF content on your own hard drive is problematic.
Are there utilities that extract PDF field data and submit it to a database? I'd be grateful to see examples.
What about field validation? The PDF may have some minor validation, but that's no substitute for the validation done in a DBMS.
If you want users to be able to save a nice looking form, you'd still want the data entered online directly into a DBMS. I'd offer a "download PDF of your input" as an option, for example.
A lot of people don't care, because they come from forms in cartaceous - where they have to manually retype everything anyway. For many, their "DBMS" will be an Excel sheet with a dozen rows. The more advanced types likely have some Adobe software that does all the magic.
Fillable PDF forms are really seen as a courtesy to users more than anything particularly useful to the emitter.
Sure, its a structured format, so you totally can extract the individual fields. AFAIK Adobe sells a server product that does that, but I'm sure there's competitors and I have seen the underlying parsing in feature in PDF libraries before.
That said, plenty of users of PDFs have a very paper-based/manual workflow still, and not the motivation and expertise to run and update an online form thing. Or they need to have the ability to handle odd inputs anyways, because paper forms have even worse input validation.
And from a browser/user perspective, the feature here is useful because people expect me to handle PDFs and do not provide nice web forms. They might have terrible reasons for doing so, but I still need to live with that.
Well, if the form needs to be faxed (still a thing!) then having the filled PDF makes it easy to use an e-fax service. But I assume sending the file to another computer for printing is the main use case.
Last year applying for jobs most places had a pdf form, if you were lucky it was an actual form too! So, filling the form and emailing it back is useful -- much better than trying to overwrite text with a PDF background; far better than printing the form, filling with a pen, scanning, then sending.
That built in PDF viewer is another feature that could have been an addon. It's bloat which increases the browser's attack surface. It's completely unneeded given that just about every OS ships with some kind of PDF reader out of the box.
It's a js application and thus less exploitable than your average C application with tons of unsound code, but IIRC it belongs to the class of "privileged js" layer that Firefox has, so has special rights that usual website js doesn't have.
The built-in PDF reader on Windows is literally to open the PDF in Edge.. so not very good UX for Firefox and also a good argument that browsers are expected to have PDF readers.
Thank Google - Chrome was the first browser to ship with a pdf reader, and people loved it. Now it's just expected that any browser should have a workable PDF reader built-in.
I would like to see Mozilla modularize Firefox more. Browsers are such huge beasts that contain everything imaginable plus the kitchen sink these days. It would be nice for these kinds of features to be add-ons that can be disabled or deleted if their functionality is not needed or desired, freeing resources for other use.
They can be part of the initial install so that Mozilla can provide the browser as they envision it, but be able to be removed for those who have other ideas of what their browser should consist of.
I don't know how technically feasible that is with their code, but it makes sense to me from a developer standpoint.
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've had to fork it internally and work on typescript bindings and other features to get it to work.
They seem to have a silly policy of only allow developers to use a subset of the API not the whole API itself so that it doesn't look like PDF.js (which I don't understand).
A lot of the functionality just isn't available otherwise.
I've been working on an internal tool for my company using the same library. It's saved me a ton of work, but my experience has been similar to yours. I've even had to lock in to a much older version for want of putting a lot more work on my plate since the API seems to have changed a fair bit. (well, between it and JSDOM which I am using to some rendering on the server). And like you I've had to write a bunch of the bindings/definitions myself or just reduce them to nil (declare module "yadda/yadday/thing" as any)—which is thankfully permissible since it just needs to be built once and run "forever" with near-zero need for feature additions, etc.
All to extract images in a routine fashion.
Just the same, I'm still immensely thankful they've published the library as OSS.
Unfortunately, it and Poppler, and Imagemagick, etc were all off the table. I was confined to running everything within a Node instance. Couldn't make calls out to command line tools. I tried probably 20 ways of using Poppler-based libraries to no avail.
It definitely would have been the better performing route, and simpler to implement. As it is, since the app is low traffic for actual processing of the images it doesn't matter too much, thankfully.
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 mature we could probably expose some more base the version off of that.
As for the "so that it doesn't look like PDF.js", we don't limit the API because of this. That suggestion (which I don't totally agree with) came from what we saw people doing, where they'd copy the entire viewer, when it'd probably be better to just let the user's browser choose how to show the PDF.
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.
PDF.js already supports h/j (and p/n) keys to page up and down. (I added them years ago. :) I think GP is asking for the keys to scroll the page by smaller steps instead of page up and down.
Do you have, by any chance, any good resources on PDF.js? The README on the github is ok, but it doesn't really cover what workers are supposed to do and provide any useful mental model for the architecture of the whole thing.
Looks cool! On a sidenote, I've always been curious with product sites: what's your metric for including other orgs under "Used and Trusted by Top Organizations"? How do you know they use / trust it?
Sheesh, 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, like it or not PDF is a de facto standard of the web, in the same way that Flash was nearly a de facto standard before the industry-wide decade-long effort to kill it. A browser that doesn't support PDFs is as lacking in the eyes of users as a browser that doesn't support PNGs.
If Flash was rendered natively in the browser, sandboxed and across different browsers, and with high enough performance/low enough battery impact, it would have stayed.
There were efforts similar to PDF.js to run Flash content using JS but they were never able to tick all those boxes.
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 than a lot of AV products, but no I don't think it's reasonable to bundle it into the program that's supposed to be here to render web pages for me. (Similar arguments, to varying degrees, are made against WebRTC and Pocket)
I really don't see why it should be an independent application. I mean it's not like we expect a PNG viewer or HTML5 video viewer to be a separate application in a browser. Being able to view (and in this case fill/interact with) PDFs is pretty much a basic necessity on the web. Beyond the core HN crowd, almost nobody cares to have a 3rd party application that they have to install to view PDFs in their browser. Having a lightweight and secure PDF viewer that is also not made by some 3rd party company that could be collecting any amount of data on you is a good thing in general.
> I mean it's not like we expect a PNG viewer or HTML5 video viewer to be a separate application in a browser.
PDFs are generally an actual document, separate from the site they're on. If images and videos weren't a part of the web pages being viewed, I would be quite skeptical of including them in the browser. I mean, there are JS viewers for STL files (https://www.viewstl.com/) - should browsers include a 2D modeling environment?
> Beyond the core HN crowd, almost nobody cares to have a 3rd party application that they have to install to view PDFs in their browser.
See, I have the exact opposite experience; I've had less-technical family complain to me they were annoyed at Firefox because it stopped just opening PDFs in Adobe and forced them into a crippled slow viewer inside itself. Unfortunately, I can't tell which of us is in a bubble.
> Having a lightweight and secure PDF viewer that is also not made by some 3rd party company that could be collecting any amount of data on you is a good thing in general.
That many PDF viewers are awful is an argument for making a better PDF viewer, but not for baking it into a browser.
> PDFs are generally an actual document, separate from the site they're on. If images and videos weren't a part of the web pages being viewed, I would be quite skeptical of including them in the browser.
See, I don't really agree with that because to me, PDFs are a pretty core part of content on the internet that users browse to via their browser. Pretty much every restaurant makes their menu available on their website as a PDF document. Almost all users will interact with PDF documents while browsing the web at some point or the other. Otoh, a tiny fraction will even know what an STL file is, let alone care about opening/viewing one. So that comparison really isn't a fair one.
> That many PDF viewers are awful is an argument for making a better PDF viewer, but not for baking it into a browser.
That's a bit of an odd statement. If anything, it proves exactly why this is a good move from Mozilla. The PDF standard has been around forever, and yet there is a dearth of free, high-quality PDF viewers that aren't bloated or filled with ads or spyware or trying to get you to upgrade to a paid version of their software. So Mozilla has finally taken matters into their own hands and provided a pretty good, light-weight and integrated solution that will do the job for most users. Power users who care can still enable other software via the plugin system as their default PDF viewer. I'm not sure how you can blame Mozilla for addressing a very real deficiency in the state of available software for PDF viewing.
Okular can handle basically everything for me, except for those Adobe-proprietary ones that require JS and all kinds of other dumb features that only Acrobat supports.
I recently made the switch to gnome as the multi-monitor support, fractional scaling and general Wayland support is only excelled by sway. I sorely miss Okular!
Can't you still run KDE apps under Gnome, even with Wayland? I use a few. Some of them look better with the "QT_QPA_PLATFORM=wayland" environment variable.
I just use Libreoffice Draw to add text into stubborn pdfs on windows and any on Linux. It's a good, free OSS way to get the job done, though not pretty.
I have a feeling this thread has a strong bias from highly automated valley life. In more provincial regions and even just much of Europe lots of forms have to be filled out and printed.
It is not something you have to everyday or something, but the existing solutions suck massively. You either have to use Adobe, which requires Windows (or Mac, I suppose) and your firstborn or use some massively shady online service. So personally, I love this feature!
(And I also do not think that this will halt all other development at Mozilla like some comments here imply)
> In more provincial regions and even just much of Europe lots of forms have to be filled out and printed.
This is changing quickly with the covid pandemic. One of its silver linings is that I can't remember the last time I had to wait in line for one hour only to be told off by some exhausted bureaucrat about my missing grand-parents' birth certificate or whatever the hell they come up with. Take that, bureaucracy!
PDF support in Firefox is one of the most important additions in recent years. My gripe with Mozilla was they're pursing all these side projects when they really should be targeting feature parity with Chrome. That's the only way people will ever switch.
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.
> My gripe with Mozilla was they're pursing all these side projects when they really should be targeting feature parity with Chrome. That's the only way people will ever switch.
A bit off topic from the post at hand, but my gripe was the opposite. The relentless pursuit of parity made them indistinguishable giving users no reason to switch (and taking dev time away from distinguishing features). Granted the pursuit of users instead of principles is its own folly that's hard to overcome when money is needed.
I'm curious what you notice is missing in terms of feature parity. I'm mostly a back-end developer (not diving into devtools very often) and switched a year ago. I'm much happier and haven't looked back.
Please file bugs for these. Also, to the author of this comment: please file bugs for these. (I work for Mozilla and yet I'm pretty lazy about bothering to file these.)
This kind of problem also happens when developers only test on Chrome. Or if they are using Chrome-specific features and don’t properly handle failover.
I just found out that this feature was coming last night, and I hadn't realized that today was release day! I did discover that if you want to enable it on Firefox 80, you can toggle `pdfjs.renderInteractiveForms` in about:config
I've built fillable PDFs for a manufacturing business. Links are provided within to the company website to the PDF files, which typically now open in the browser, with varying degrees of reliability. Unfortunately, many people assume this is just another page of the website and that they should be able to interact with like any other web form. Always fun trying to explain this.
I actually like the pdf.js viewer enough that I use the chrome extension version on chromium. But I see it hasn't been updated in over a year now. Hopefully it will get updated!
Any chance Firefox will have built-in support for printing to PDF? There's a browser extension[1], but it was last updated 3 years ago. Seems the Chrome browser has had this feature for ages.
It's not ready for release yet, but if you flip the preference `print.tab_modal.enabled` to true you'll get the replacement printing interface which has a "Save as PDF" pseudo-printer.
On Windows at least, using the built-in PDF printer with Firefox results in text in the PDF file being converted to paths (not text). Huge file and you can't copy/paste. I've tried 3rd party PDF printers (PDFForge) and the result is the same, so I think it might a FF bug (or feature)?
Chrome's save-as PDF produces actual text. It's the main reason I still have chrome installed.
That seems.... odd. I am on Firefox on Windows and I print to PDF all the time using the Windows built-in PDF printer ("Microsoft Print to PDF"), without issue. In fact sometimes that printer is the only one that can get things to format correctly!
Something on your system might be interfering with the printing process.
There must be something strange your particular set up, or maybe the behavior changes based on the page. Firefox 81, Windows 10 version 2004, multiple computers, printing this page with the "Microsoft Print to PDF" printer this page of comments all result in a PDF of ~470KB with selectable text.
> After entering data into these fields you can download the file to have the filled out version saved to your computer.
And then what? Fax it? Sounds like a missed opportunity to me. It would be nice if you can add a Submit button to have the data posted to the server, just like any other web-based form.
I haven't printed a PDF to sign in years. Why don't you just affix a digital image of your signature to the file? Save it and email it back to whomever.
383 comments
[ 5.4 ms ] story [ 292 ms ] threadIs there a version of Firefox that removes this bloat?
Given that Mozilla is very resource constrained, why are they working on features that aren't necessary?
I don't want to start explaining to my mother, over the phone, how to install and use the pdf viewer anymore :|
I think Mozilla's line of thought here is that PDF documents are widespread in the web, to the point where they are a de facto web document type. So it makes sense for a web browser to support them rather than calling out to a user's desktop program (though I assume you can configure it to do so instead).
There's probably a bit of "our competitors do it, so we have to too" in there as well.
And the reasons for not requiring an outside PDF reader are major: It's yet another likely-to-have-vulnerabilities program people need to install, then update. In most cases, avoiding Adobe programs on your PC is a good way to avoid a lot of vulnerabilities.
Chrome/Chromium uses PDFium, not PDF.js, so no. Not sure about Edge.
PDFium has been able to fill out forms for a long time. What’s new for Chrome is the ability to save edited PDF (as fillable).
However, I was able to confirm that Edge uses extension ID mhjfbmdgcfjbbpaeojofohoefgiehjai to render PDF internally[1], same as Chrome, so indeed it's using PDFium.
[1] The rendered PDF element would look like
And here's the extension's manifest in Chromium source, where you can find the extension ID: https://github.com/chromium/chromium/blob/2baa2b094cdd60e980...And I also like that I can preview long-form PDFs in the browser, before choosing whether to save them and read them “for real.”
Imagine if every time you opened a direct-linked JPEG image in your browser, it treated it as an attachment, downloading it and opening it in your external image-previewer app, rather than rendering it as a synthesized HTML DOM wrapper around the image. Wouldn’t you be annoyed by how cluttered your Downloads directory would get with random files you never actually wanted to save?
Having a sandboxed PDF viewer that works 95% of the time is great. For those 5% circumstances where I am actively trying to view a PDF and it won't work in browser, I'll gladly go through the minimal effort to open it in an external viewer.
Of course, I do wish Sumatra supported filling forms. Then I could uninstall Firefox too! ;-)
If we simply had print-to-HTML functionality which resulted in a document identical to what you view onscreen while editing, PDF could die the death it deserves.
But HTML+CSS somehow manages to suck just as much for common usage, so it persists.
In the sense of a “form” just being lines on paper that you can arbitrarily add some text to — no, that’s easy.
Likewise, in the sense of a “form” being some defined input regions that accept your keystrokes and turn them into new text DOM nodes in the PDF itself — easy enough. Though, unlike HTML, there’s no concept of an <input> tag that just has the semantics of accepting keystrokes and turning them into (persisted) input; instead, this all has to be done through scripting [i.e. writing event-handlers, or having some PDF authoring software generate them]; and there are several incompatible scripting languages for PDF that get used, some of which are proprietary with no open specification.
But, doing form validation? Or, worse yet, making one of those fancy PDF forms that auto-calculates fields like an Excel spreadsheet? Now you’re getting into the hairy stuff, because IIRC none of the open-standard PDF scripting systems provide these sorts of mechanisms, so these are inherently proprietary things.
And when I say “proprietary”, I mean “like old versions of Word or Photoshop, where each version emitted its own in-memory data-structures to disk without formal serialization; and it was the job of authors of future versions to write importers to deserialize whatever format resulted.”
And implementing a PDF viewer is already a major undertaking; adding the form functionality complicates things even more.
The vast majority of form is indeed not « ready » for input, requiring users to go through hoops to fill them. And that work is done again by the next person.
The problem I was referring to, is when one is expected to fill a PDF that was not built to be filled, such as the scan of a paper form.
Uh, what? Firefox supports javascript. PDFs support javascript. Javascript empowers tracking.
https://github.com/mozilla/pdf.js
- every browser that supports cookies comes with a tracking package
- electron comes with a tracking package
- every language interpreter, runtime or compiler is a tracking package.
- your OS can run tracking software, thus coming with a tracking package.
- Anyone carrying their phone comes with a tracking package
Hang on, did you just post something on the internet? Your HN account comes with a tracking package!
OK, Firefox is, sadly, far from being a mainstream browser nowadays, but still I suspect it has a larger user base than Poppler.
Do you see the problem in all PDFs? Maybe there is something unique to the PDF you are searching?
Sure we do. There are plenty of proofs out there that pi is an irrational number.
It's then trivial to see that every number you can think of is encoded in there, and therefore any data, piece of music or movie that ever existed.
(I'm not sure we're allowed to fiddle with the encoding, but since we allow ourselves to represent a piece of music into a number, we're already talking about encoding anyway, so it doesn't seem like cheating to me...)
Also, 1.01001000100001... is a good example of a number that is both irrational and transcendental but not normal.
According to wikipédia, you gave a definition for "simply normal", and for normal numbers the distribution of any sequence of digits is uniform. So 00, 01, ..., 99 each occur uniformally too.
We don't know whether pi is that either for any integer base.
The first place a valid PDF could be ended, perhaps.
you're just pasting random python snippits at me now. It's time to move on.
again, just to summarize: PDF files do not have to be zero aligned, and they do not have to be end aligned. Therefore the answer to the question "what is the first segment of Pi that is a valid PDF file" is trivially (0,infinity). That is a correct statement. The non-greedy (in the regex sense) answer to that question will be different, however.
Note the word "next", implying that (0,10) sorts before (0,11); you even say it yourself "11 is less than infinity". Where I'm from "first" and "less" are related (the first element in a unique sorted list is defined to be less than all other elements). So if there is any valid pdf in pi that can be identified by the range tuple (0,N), then the first valid pdf must occur before N -> infinity. Therefore (0,infinity) can never be the first valid pdf, even though it may be a valid pdf.
Maybe a picture would help:
I thought linking to a python script that shows the order comparison of a tuple (0,N) as less than the tuple (0,N+1) would clearly demonstrate this, but it appears to have failed to communicate that to you. We don't need non-greedy regex rules to do a less than comparison.Including a PDF that generates the digits of pi
I understand the point that PI contains every possible piece of information, theoretically.
However, the chance of finding a given string in PI depends on the string’s length. The longer the string, the more the probability tends to 0.
The paradox therefore is that PI contains every PDF, but you will never find them, so in what sense does it really contain them at all?
Are you saying that:
- given a long string, we might ask “can this string be found in PI?”
- the probability of finding a long string in PI is infinitely small
- the number of possible strings in PI is infinitely large
- it’s not possible to decide if the answer is yes or no?
Probably won't send it to any recruiters, but it will be a funny anecdote for interviews.
And even places with strong roaming rights tend place limits on well marked land.
[1] https://www.pdflib.com/pdf-knowledge-base/pdf-password-secur...
https://sources.debian.org/patches/pdftk/2.02-4/drm_fix/
I've read a few comments on HN how PDF is, well, not developer-friendly. If people are interested in providing some more examples here, I'd be curious to know!
The old .Doc and .xls files were a bad format, but my understanding is that since Office 2007 the format is generally much better.
Streams just suddenly end? That’s ok. Totally corrupt xref tables? Ok. Incorrect image headers? Ok. Unrecognisably mangled Type1 font formats? Fine!
I personally think the structural PDF format is a really great format. It's entirely ASCII-based, a pure text format, yet it can embed arbitrary binary data and compress that data. The actual structure is simple and support just enough functionality, like a tree of object, dictionaries and arrays, unicode strings, date formats, etc.
I think if you limit yourself to pure structural PDF woulde have been a great format to standardize upon, much better than JSON or XML. It';s richer than JSON, simpler and saner than XML. Again, it's top-notch ability to embed binary is great. It has other great characteristics, for example you can update anything just by appending.
The ugly bits are in the "semantic" PDF: the page descriptions, media, etc. Even then, the early version of PDF were nice, mainly just simplified Postscript.
A common case is clients who use utilities that generate single customer documents then merge them into a bigger file for bulk print and mail (bills and statements, not identical copy). Without fail that results in thousands of similar but different subset fonts whereupon most printers I've encountered eventually fail due to memory issues.
Typically this leads to a discussion about "I can open it on my computer fine" and bending over backwards to find a workaround. Merging and consolidating these fonts doesn't seem to be a simple task, although some tools claim to work some of the time.
Something that scopes object resources for disposal could be nice in the PDF spec (maybe it exists), but something like a LRU caching mechanism on the printer would potentially resolve this too.
- Clipping path logic, you can write text outside of it, which makes it effectively invisible yet it will show up if you try to extract the text.
- Anything regarding the graphicstate stack, it's a pain to debug.
- Extracting content from AcroForm/JS "XFA" forms
PDF is great format for printing, it's just a pain for pretty much everything else.
My other one is the use of multiple subset fonts that are actually the same font with a different subset of glyphs that you want to merge back together.
Having said that (and worked on a commercial PDF library), despite all the cruft that came with age, it's a well built format that survived the test of time with good reasons.
I worked on a Pdf with inbuilt tracking solution that updated the form layout using ActionScript based on the workflow status and the role of the user (ie the line manager had a different group of fields in the form to complete like their signature while viewing what the initial requestor had entered) Lots of callbacks to the server saving in progress data and updating the status of who had the form, who was next based on department and emailing it to that person if it passed validation.
An initial fun discovery was that you could force the form to download and replace itself with the latest version even if they had just opened some old file they had on their pc.
EDIT: oh yeah, I'm pretty sure it contains Mail, just like Zawinski said
A lot of the time developers want access to the text inside PDFs. Unlike HTML or formats like MS Word (XML or old binary format) getting "text" isn't really possible.
Most "document" formats have the concept of words or strings: a set of characters separated by whitespace. PDF isn't a "document" format in that sense - it's a page description language. Instead of strings of text you have character glyphs positioned at a particular location.
If you want to "read" the text, you have to work out the orientation (which can change throughout the page - think of table header alignment), and use some kind of heuristic to guess the word spacing based on the font and character spacing.
There's also this whole thing with clipping, where some text can be hidden behind other objects (or off page) so you have to try to deal with that.
There's lots of libraries that try to do this for you, but there are lots because none get it right 100% of the time...
As far as I know, any PDF can be losslessly converted to an equivalent PDF that can be edited in any text editor, even Notepad. And yes, you could fill in the forms there, too (if you were stubborn enough)
Again, as far as I know, there are no heuristics good enough to get that right for all values of PDF.
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.
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...
See http://blog.idrsolutions.com/?s=%22Make+your+own+PDF+file for more info on how to write PDF by hand (also shows why I said you have to be stubborn to do that)
You are trying to move the goal post here. The above statement is simply untrue, PDF is not a text based format and it's that simple.
Look at Chapter 3, Syntax. The code is all text based. We are not talking about the visible characters in a PDF viewer, but the code of the PDF file itself.
BT /F13 12 Tf 288 720 Td (ABC) Tj ET
This can be extended to include spaces so you can essentially mark up entire lines of text at one time. What it can't do is cohesive paragraphs and flow/wrap, you need to use the relative positions to work out what text is in one block (and usually I'd defer to something like pdftotext for simple cases).
Laying out individual characters is common though. It's probably due to kerning concerns.
I silently thank every architect that provides searchable PDFs, it makes my job way easier
Look at Chapter 3, Syntax (and the rest of it, really).
I literally have scripts that use bash and sed, or Python, to modify PDFs by editing the text code. Doing it in Notepad is possible but tricky, as there's a table of object byte offsets near the end that it's easy to mess up by inserting a character.
...a wondeful novel along these lines. They only get shot and kidnapped though. Nothing so bad as PDFs.
Well, at least, pdf is probably better than printed paper for that purpose.
Ended up just making the app generate HTML before calling wkhtmltopdf.
The PDF spec is insane! But like all things what you get out of Word/OpenOffice is 100x more complex than if you wrote it yourself, which is indeed doable.
https://github.com/phpdave11/davepdf
https://github.com/phpdave11/gofpdi
https://github.com/catseye/pdf.lua
Mozilla's pdfjs[1] project is a pure HTML/JavaScript solution for PDF rendering. This is the same code that ships in Firefox browser as well. This is standalone, AFAIK, it doesn't talk to a mothership.
[1]https://mozilla.github.io/pdf.js/
I will be extremely surprised if anyone (besides Adobe) has implemented 100% of it.
That is truly nightmare material. Especially considering a non-trivial percentage of pdfs circulating are non-conformant and people still expect them to render...
For a local web use, I built for myself https://formulairemagique.fr for this very reason
It and terminal.app have survived the thing Apple does where they update applications and remove all the application’s power to achieve anything.
PDF is a dork. It's an accessibility nightmare with no obvious advantage over simple ordinary webpages. Somewhere in the comments below, it is mentioned that supporting PDFs is a non-trivial piece of technology. May be! Even steam engines have non-trivial technology under the hood.
Why don't you list all of things that PDFs can do that can also be done with web pages?
There's nothing a PDF can do that a webpage can't. In fact there are a hundred of things that a webpage can do, but a PDF can't. Including, form fields, input fields and seamless form submissions.
Webpages can also do this: https://bubblin.io/cover/official-handbook-by-marvin-danig#f...
Disclosure: It's my work.
PDFs are easy to make and easy to work with. Web pages aren't.
Your work is impressive, and why would anyone want that? Do you envision lawyers putting all their legal contracts into fancy flippy books?
Someone will have to solve it for the lawyers in a not so 'fancy consumerish' way. Point is that it is possible to do that, and Firefox shouldn't be solving this problem using an ancient format and a layer of cruft in between.
You can be a developer who enjoys the smell of your own farts all day long but that doesn't mean anyone else wants to smell them.
That was the entire point of my comment at the top.
When a PDF that has interactive form fields, calculated auto-populated fields, fields that are enabled/disabled according to the inputs of other fields, etc. — the organization that created it (usually government or education) usually does that because they want you to fill it out using a PDF viewer; save it (which will persist the form inputs “into” the resulting PDF); and then submit the modified PDF file back to them. They want this, because they can use automated backend processes to extract the data from the PDF. They don’t want you to just print out the thing and fill it out. In fact, many such “fillable” PDFs start off in a state with many of their form-fields disabled and voided, such that printing them out in that state would result in a form you can’t really write on!
So, at that point, why didn’t they just make the PDF a web page? They’ve essentially reinvented a web form, but with extra steps. The only benefit a client gets is the ability to edit and save the form offline (but that can be done in a browser, too, with local storage); and furthermore, the ability to treat the resulting filled form as a file, moving it around before you submit it. But the cases where you need that are very niche, compared to the cases where you can just direct employees to your Intranet portal.
I have never seen this. Do you have an example? Every use if fillable PDFs I have encountered is a use case where submitting a handwritten form is still an option.
> The only benefit a client gets is the ability to edit and save the form offline (but that can be done in a browser, too, with local storage); and furthermore, the ability to treat the resulting filled form as a file, moving it around before you submit it.
I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy.
> But the cases where you need that are very niche, compared to the cases where you can just direct employees to your Intranet portal.
This is not a trivial need; most forms sent as fillable PDFs need to or should be retained for some period after submission. Also, I don't know what "employees" and "Intranet" has to do with anything.
You are also missing the use case where a form legally requires a live signature from one or more parties and need to be printed, even if just to scan and return. I recently had to do this for some insurance paperwork.
My company have to do this for one state government. They required the signature to be written black inked. It is PITA to do since we all have digital signature set up. But nope, this state government required the written signature.
I don't have one on-hand, no. But I've certainly had to fill them out in the past. IIRC an especially-bad one came in the form [heh] of a student-loan application for the college I attended. It was essentially a Hypercard stack in the guise of a PDF.
Here are some early Adobe marketing materials (as a PDF, because of course it is) talking about the advantages of "eForm Solutions": https://planetpdf.com/planetpdf/pdfs/pdf2k/02E/ldefurio_pdff...
It sounds like every PDF form you've ever dealt with is what Adobe, in this brochure, calls a "Type 1: Print and Fill" or "Type 2: Fill and Print" form. But Type 3 and Type 4 forms do exist in the wild! (They're not often created any more; most of the ones that exist now are from around a decade or two ago, when Adobe was really pushing this idea.) Creating such forms was basically the point of Acrobat as a software product.
When PDF viewers (e.g. Apple Preview) say they don't support "PDF forms", they're not talking about Type 2 forms. They usually support those just fine. They're talking about Type 3 and Type 4 forms. And more specifically, the ones that use Adobe's proprietary AcroForms data-embedding system, rather than the open-standard XFA data-embedding system.
(I could swear I saw an HN post about the horrors of AcroForms once, but I can't find it now.)
> I have yet to see a web form that actually saves a readable, properly-formatted, self-contained, easy to access, fully-offline copy.
To be clear, that was what I meant by the second qualifier, "as a file." Browsers support persisting the state of the form. Just, not as a file. They persist the state internally, when the form's author does the client-side Javascript work to enable that.
For the use-case where the user wants to stop filling out the form for now (e.g. because they don't have some required information on-hand), and then come back to it to finish it later, in-browser persistence works perfectly well.
Even cleaner, though, is just building a web-form as a wizard, where fields are submitted one-at-a-time, and you can also freely navigate to previously-filled "steps" to change your answers. That doesn't even require JavaScript; just pure 90s HTML-generated-on-the-backend. Most government sites that thought PDF eForms were a good idea, are now falling back to this approach.
> Also, I don't know what "employees" and "Intranet" has to do with anything.
Secure installations. The main use-case for fillable PDFs (as can be seen in Adobe's marketing brochure, where "government" is the core client) is a case where public or cloud solutions just aren't tenable, i.e. in secure government/military/etc. installations, where the workstations are air-gapped from the public Internet. In such a case, PDF forms can still be sent around via a local non-Internet-routable email server, for the workers there to fill in.
Today, this need can be served just as well by setting up a non-Internet-routable web portal for those same workers to use. But back in the 90s and 00s, "Intranet web portals" were a fancy thing only the most forward of IT bigcorps had on offer. They had Intranets, for sure, but they weren't hosting web-apps on them.
So, what did they do instead? Well, Adobe had two main competitors in the "eForm" market:
• Lotus Notes form documents, connecting to a Lotus Domino database server;
• Microsoft Excel sheets that use VBA to data-bind to an accessible Microsoft Access database file sitting on an SMB network share.
None of these "forms" were hand-submittable. They're all little self-contained interactive applica...
2. IT person + webserver costs have to included in the budget somewhere. Which can be a big problem.
3. The webpage form can fail, and the support for it has to be provided by the IT dept. If the PDF form fails, dept can handle it on its own, and will often accept a filled+scanned print out of the PDF form.
4. Adding to the point above, PDF forms degrade gracefully, If they don't work, or internet doesn't work, or someone is on holiday, you can still print, fill and hand them in person. Webpages can degrade catastrophically where you whole dept grinds to halt while the IT person tries to fix the problem.
Instead, I'm talking about the PDFs you can basically only load in Acrobat (though, other PDF viewers do try to render them, to varying success) that actually do data-binding to some remote database; do XHRs to submit the form data on success; do "online" onBlur-XHR-esque field validation; generate new output PDFs using scripting, from scratch when you ask them to save/print; etc.
These are applications, not documents. You can't print them. You just use Acrobat as a glorified application host to fill and submit them. (You can press Ctrl+P to get Acrobat to request to the loaded PDF application that it perform some scripted action to generate a print output. This may or may not do anything, depending on how the PDF was created. It usually just pops a "Printing is not implemented for this form" box. It certainly won't work in non-Acrobat PDF viewers.)
When other PDF viewers say they don't support "fillable PDF eForms", these are the things they're talking about. They usually support "Fill and Print" forms just fine, because "Fill and Print" forms are a somewhat-sane format, rather than being a competitor to Lotus Notes.
The benefit of these forms is that the validated form that you submit online is actually printable. Which means that what you see on your screen/paper is pixel by pixel identical to what Canada receives, and therefore _legally_, there is no confusion about what was communicated between Canada and the candidate.
Webforms are not as strongly accepted as such by courts. Because they have to be manipulated further before being printed.
I have read a bunch of your replies, and you are thinking of all the technical reasons why webforms are better than PDF (you are right in that), but PDFs have legal and operational and budgetary advantages, that are more relevant to various organizations.
It is easy to criticize something when you don't look back at the historical context through which it emerged. It has plenty of advantages over HTML but they're easy to dismiss if you don't have a use case for them.
Can you discuss some of the advantages? The only advantage that comes to mind is that Apple has built-in support for writing PDFs and that has a lot to do with Adobe rather than PDF being a better candidate.
If you think MSOffice users would prefer to output HTML over PDF, you don't live in the same corporate world I inhabit.
Also, cryptographic signatures do happen to be a feature of PDF.
What I meant to say is that Firefox should focus on implementing cryptographic signing over HTML then. And not a PDF viewer on the web--in that, enabling cryptographic signatures isn't tied to the format PDF per se.
How are PDFs any less modifiable than HTML other than requiring (widely available) specialized tools instead of a text editor?
I doubt "all" their money goes towards the pdf-reader bit. And tbh, I'd say nobody will really lower their goodwill towards Mozilla because they add features that a lot of people actually need.
What’s the use case? Printing out filled-in forms? But otherwise, who would want the PDF in electronic format? It doesn’t seem like a practical way for users to submit data.
Are there utilities that extract PDF field data and submit it to a database? I'd be grateful to see examples.
What about field validation? The PDF may have some minor validation, but that's no substitute for the validation done in a DBMS.
If you want users to be able to save a nice looking form, you'd still want the data entered online directly into a DBMS. I'd offer a "download PDF of your input" as an option, for example.
A lot of people don't care, because they come from forms in cartaceous - where they have to manually retype everything anyway. For many, their "DBMS" will be an Excel sheet with a dozen rows. The more advanced types likely have some Adobe software that does all the magic.
Fillable PDF forms are really seen as a courtesy to users more than anything particularly useful to the emitter.
That said, plenty of users of PDFs have a very paper-based/manual workflow still, and not the motivation and expertise to run and update an online form thing. Or they need to have the ability to handle odd inputs anyways, because paper forms have even worse input validation.
And from a browser/user perspective, the feature here is useful because people expect me to handle PDFs and do not provide nice web forms. They might have terrible reasons for doing so, but I still need to live with that.
AFAICT PDF.js is just another JavaScript application and thus as sandboxed as any other website.
They can be part of the initial install so that Mozilla can provide the browser as they envision it, but be able to be removed for those who have other ideas of what their browser should consist of.
I don't know how technically feasible that is with their code, but it makes sense to me from a developer standpoint.
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've had to fork it internally and work on typescript bindings and other features to get it to work.
They seem to have a silly policy of only allow developers to use a subset of the API not the whole API itself so that it doesn't look like PDF.js (which I don't understand).
A lot of the functionality just isn't available otherwise.
All to extract images in a routine fashion.
Just the same, I'm still immensely thankful they've published the library as OSS.
It definitely would have been the better performing route, and simpler to implement. As it is, since the app is low traffic for actual processing of the images it doesn't matter too much, thankfully.
This library was helpful: https://github.com/ScientaNL/pdf-extractor
I haven't had time to do it cleanly, but I should contribute back with the types I wrote after cleaning them up...
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 mature we could probably expose some more base the version off of that.
As for the "so that it doesn't look like PDF.js", we don't limit the API because of this. That suggestion (which I don't totally agree with) came from what we saw people doing, where they'd copy the entire viewer, when it'd probably be better to just let the user's browser choose how to show the PDF.
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.
https://github.com/mozilla/pdf.js/blob/83e1bbea6e23db8744420...
https://github.com/mozilla/pdf.js/blob/83e1bbea6e23db8744420...
PDF is fine to be some binary blob to download just as most other binary blob formats are.
Would you expect to have .exe files being directly interpreted by a browser?
no, i wouldn't. and yet here we are: wasm.
There were efforts similar to PDF.js to run Flash content using JS but they were never able to tick all those boxes.
PDFs are generally an actual document, separate from the site they're on. If images and videos weren't a part of the web pages being viewed, I would be quite skeptical of including them in the browser. I mean, there are JS viewers for STL files (https://www.viewstl.com/) - should browsers include a 2D modeling environment?
> Beyond the core HN crowd, almost nobody cares to have a 3rd party application that they have to install to view PDFs in their browser.
See, I have the exact opposite experience; I've had less-technical family complain to me they were annoyed at Firefox because it stopped just opening PDFs in Adobe and forced them into a crippled slow viewer inside itself. Unfortunately, I can't tell which of us is in a bubble.
> Having a lightweight and secure PDF viewer that is also not made by some 3rd party company that could be collecting any amount of data on you is a good thing in general.
That many PDF viewers are awful is an argument for making a better PDF viewer, but not for baking it into a browser.
See, I don't really agree with that because to me, PDFs are a pretty core part of content on the internet that users browse to via their browser. Pretty much every restaurant makes their menu available on their website as a PDF document. Almost all users will interact with PDF documents while browsing the web at some point or the other. Otoh, a tiny fraction will even know what an STL file is, let alone care about opening/viewing one. So that comparison really isn't a fair one.
> That many PDF viewers are awful is an argument for making a better PDF viewer, but not for baking it into a browser.
That's a bit of an odd statement. If anything, it proves exactly why this is a good move from Mozilla. The PDF standard has been around forever, and yet there is a dearth of free, high-quality PDF viewers that aren't bloated or filled with ads or spyware or trying to get you to upgrade to a paid version of their software. So Mozilla has finally taken matters into their own hands and provided a pretty good, light-weight and integrated solution that will do the job for most users. Power users who care can still enable other software via the plugin system as their default PDF viewer. I'm not sure how you can blame Mozilla for addressing a very real deficiency in the state of available software for PDF viewing.
It is not something you have to everyday or something, but the existing solutions suck massively. You either have to use Adobe, which requires Windows (or Mac, I suppose) and your firstborn or use some massively shady online service. So personally, I love this feature!
(And I also do not think that this will halt all other development at Mozilla like some comments here imply)
https://www.microsoft.com/en-us/p/okular/9n41msq1wnm8?active...
This is changing quickly with the covid pandemic. One of its silver linings is that I can't remember the last time I had to wait in line for one hour only to be told off by some exhausted bureaucrat about my missing grand-parents' birth certificate or whatever the hell they come up with. Take that, bureaucracy!
Like PDF support?
A bit off topic from the post at hand, but my gripe was the opposite. The relentless pursuit of parity made them indistinguishable giving users no reason to switch (and taking dev time away from distinguishing features). Granted the pursuit of users instead of principles is its own folly that's hard to overcome when money is needed.
* blank pages when trying to load an imgur gallery on v68 (esr).
* image uploading not working right on instagram and various other sites, either producing blank images or ones with weird lines.
* several teleconferencing / video meeting websites just don't work properly, whether it's not detecting hardware properly, etc
I have to keep chromium installed so I can use these sites properly.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Web%20Com... if you're on desktop.
https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc...
1: https://addons.mozilla.org/en-US/firefox/addon/print-to-pdf-...
Chrome's save-as PDF produces actual text. It's the main reason I still have chrome installed.
Something on your system might be interfering with the printing process.
And then what? Fax it? Sounds like a missed opportunity to me. It would be nice if you can add a Submit button to have the data posted to the server, just like any other web-based form.