91–100 of 173 posts
If you have a PDF document on your web site, please consider putting a link to https://pdfreaders.org/ instead of unfair advertisement of Adobe Reader.
Earlier quoted context omitted.
I have never seen anyone use any of these features in the real world. I presume that embedded animation and 3D extensions are used in art-related fields? If so that would explain my ignorance.
I have to use Reader to fill out my state tax forms because they use some modern JavaScript driven system to auto fill that no other reader can handle.
If you have a PDF document on your web site, please consider putting a link to https://pdfreaders.org/ instead of unfair advertisement of Adobe Reader.
Which gives (except for pdf.js) more PDF readers written in C, some with a long history of CVEs, and typically not sandboxed by default. Since many people are using a PDF reader to read PDFs from relatively untrusted sources, do yourself a favor and at least use a reader that does not have full system access. macOS: Preview.app (uses macOS sandboxing) Linux: Evince Flatpak on Wayland (Flatpak uses sandboxing. Wayland…
I think UWP apps are sandboxed by default, so something like Xodo PDF could be a possibility.
Earlier quoted context omitted.
While working with the PDF format I sometimes get the impression that this complexity is what Adobe wants. As a result, Adobe Reader is the only viewer that implements the entire spec and can handle all (or most) quirks. This is especially apparent when trying to edit arbitrary PDF files, which is sometimes not so easy or even impossible. Just the definition of fonts and the text layout is already so complicated that…
The same could be said for the Microsoft Office file formats. Or PSD, for that matter.
Acrobat Reader has been the poster boy for poor software for many years and it appears that Adobe have been good at adding new features to make it largely impossible for their competitors to keep up. What is one to do? Surely, the obvious answer is to ringfence PDF (or another new format) for the most basic features. These could more easily be handled by 3rd-party apps both securely and to render correctly. Let Adobe…
As much as many of us lament the state of much of today's software, if you think of products from a certain era - IE6, Flash, Java web applets - they all had a commonality in their code quality. These are mostly a non-issue these days, but it's not because they suddenly stopped having bugs and still get active use. I remember rolling out Adobe Reader in those days and as a product, I don't believe its core has change…
That doesn't mean that there aren't any alternatives. Foxit for example is pretty good. But in-browser alternatives just aren't there yet
Earlier quoted context omitted.
The same could be said for the Microsoft Office file formats. Or PSD, for that matter.
The Office formats are well specified, they are complex because that is the nature of the software but it is a world away from something like PSD or even PDF.
Being able to run JS in a PDF sounds scary to a lot of people, but I wouldn't throw that idea out entirely. If you follow the work by Bret Victor & others on "explorable explanations"[0][1] and interactive scientific papers[2], you probably appreciate the need for a self-contained format for interactive documents. Could PDF be this? I don't know, I hear the spec is too scary. But I'd say we should have something like…
Distill[1] is another example of interactive scientific papers (with a focus on machine learning). But is there really a good reason to not just keep these in browser? I don't really know if there's much value in reading these locally. Maybe this would be a good fit for an electron app? [1] https://distill.pub/
That behind us, there's also a matter of reliability and control. Services live much shorter than data they process; given today's trend, I wouldn't expect an online-only paper to be available after 5-10 years. Having a self-contained bundle would let me archive it independently, and would prevent any third parties from being able to interfere with my reading/exploration.
As much as many of us lament the state of much of today's software, if you think of products from a certain era - IE6, Flash, Java web applets - they all had a commonality in their code quality. These are mostly a non-issue these days, but it's not because they suddenly stopped having bugs and still get active use. I remember rolling out Adobe Reader in those days and as a product, I don't believe its core has change…
To be fair, in my experience Chrome's and Firefox's PDF viewers don't cut it. They are good for a quick preview, but especially when printing they occasionally render things slightly wrong, which is unacceptable for a file format whose entire point is to look the same everywhere. Also forms. That doesn't mean that there aren't any alternatives. Foxit for example is pretty good. But in-browser alternatives just aren't…
Since it's such a quickly evolving project, I wondered where form support is up to. https://github.com/mozilla/pdf.js/issues/7613
Form support is not complete. Seems like it required quite a rewrite to get the foundation in a good place to finish it off.
Are there rendering bugs? Yes. See plenty here: https://github.com/mozilla/pdf.js/issues
Of course, Acrobat also has PDF rendering bugs, and other various bugs apart from the security issues mentioned (their JavaScript implementation for example).
As for printing... browsers aren't even good at printing HTML. The best browser for printing is based on the old Opera software(PrinceXML), and Safari is probably second. Remember the Apple display system used to be based on PDF rendering... and they do a lot with CUPS and graphic designers.
However, printing PDFs on many browsers can go directly to the printer or the OS (which mostly all support rendering PDFs directly now).