Views on PDF Viewers

In response to

I’ll open up this thread to avoid any more digression on the abovementioned thread.

Click here to vote.

Some views on PDF-Xchange:

Foxit Free:

On Sumatra:

There are various pdf viewers and most of them are competing on who has the most features to offer. In my opinion, the key features ought to be these three:

  1. Usability and speed
  2. Document fidelity and readability
  3. Security

Now, if we take a closer look on PDF Viewers, the difference on rendering differs based on the library they use. Now the ones that I do know are only so few, but the ones that I’ve tried uses the following:

  1. adobe pdf library (adobe reader) – proprietary, i don’t know any software that uses this aside from adobe acrobat. Offers the best rendering quality but also the heaviest and slowest.
  2. mupdf (mupdf, zathura, sumatra) – the speedy gonzales of them all; “quick and dirty”. It should be noted that, by my understanding, anti-aliasing is implemented by default which should make things look a tad bit better. However, I did hear that at times it looks overly blurred. It’s not an issue for me, but certain fonts could look a tad better. Compared to poppler though, mupdf renders images better though exceptions do occur.
  3. poppler (qpdfview, evince) – poppler is heavier than mupdf, but lighter than adobe pdf library. It has more features than mupdf, less than adobe pdf library. But it does excel at them. It was more consistent in rendering various pdf’s as opposed to mupdf’s seemingly hit-and-miss rendering. Among the free pdf software, the ones that used poppler offered support for form editing.
  4. pdf.js (firefox, chromium) – well, yeah, okay it’s not exactly a library. At this point in time, it’s more hit-and-miss than mupdf is. But it does show a lot of potential and cross-platform.

Memory-usage, I think, is independent of the library used since however heavy any of the above were (save for pdf.js, and adobe pdf which i could not test for consistency because i know of no other software that uses this library), none of them bogged down the desktop too much (1.0 Ghz processor with 224 MB of RAM, WINE via BodhiLinux). it would seem that memory usage is caused more by the framework they choose to use for its interface, the lightest of which being Qt followed by hit-and-miss GTK.

I don’t know if Nitro, Foxit and XChange View uses their own rendering library, but XChange Viewer offers more options though a tad bit more pricey. Foxit on the other hand, adds a toolbar as far as I remember, and Nitro requires you to register.

The best one I’ve tried is qpdfview which has a good balances of speed and document fidelity and form-filling, but only available in Linux as far as I can tell. Sumatra launches faster than XChange Viewer though more limited. XChange Viewer offers better rendering than Nitro. Nitro offers better form-filling functions though just as limited. Evince was slow and ugly for me.

I’d say that’s a great summary. :slight_smile:

As per PDFXchange forum, in the next few builds, option to hide pro features will be there in PDFXchange Editor.

This option was there in previous version? I never used PDFXchange so asking.

Thanks for the summary spainach_12. :-TU


Hi naren, yes the option is available with the viewer. (Screenshot)

[attachment deleted by admin]

Interesting, I have only just recently found this.
I haven’t tried it.

In order to use the Spoon service, users will need to install the Spoon plugin*.
[url=http://www.tracker-software.com/viewer_cloud_apps]Cloud Version of PDF-XChange Viewer & Viewer PRO[/url]

I’ve been wondering for some time now, how do you make a pdf secure?

Encryption?
I think encryption is a little way too over-the-top. Might as well use TrueCrypt or the ever-present WinRar. The encrypted pdf’s that can be opened for example, only prevents copying (or tries to since it can be bypassed using a screenshot). Those that can’t be opened can be printed, and well…there goes confidential data. Oh and these methods actually work. Nevertheless, it’s neither wanted nor unwanted in my opinion. Password-protection may be needed, but only so far as restricting setting changes.

Certificates?
I’ve seen quite a few trojans lately and upon close inspection, I noticed that it managed to bypass security by using fake digital certificates. Quite novel, I thought, when I first saw it. That’s brilliant. Unfortunately, that’s bad news for us. In essence, it’s proof of concept that certificates are spoofable and could give you a false sense of security, and nothing’s more dangerous than the illusion of security.

Permissions?
Oh this one is very necessary. I think it’s a good option to be able to set permissions as the basic level of security. Couple this with a password, and I think it would serve as a good starting point.

Partial sandboxing?
For downloaded pdf’s or online viewing, this would be very helpful. Opening the pdf in “Restricted view” could help eliminate a lot of potential malicious pdf’s.

Stripping hidden data?/
Hidden data may be used to identify the owner and compromise privacy. Even worse, it can be used to extract sensitive information from the document. Macros, for example, contain the user’s name in the header.

I was thinking of developing a plugin for comodo dragon instead or ice dragon, too, to give it partial sandboxing and the benefit of modular expandable capacities via plugins (i.e. advanced tab management, session saving via session buddy, viewing online pdf’s anonymously through ZenMate, checking grammar in form fields using grammarly, page annotation etc.). This makes it more flexible without getting unnecessary bloat.

I suggest though that the plugin be an optional download and not come with the browsers as the default just as google chrome did.