FULL DISCLOSURE: While I am an occasional consultant to Adobe Systems (among others), this review is objective.

Time for a fresh look

Last March we reviewed a crop of free PDF readers available for Windows. This time, we add a new contender to the list (Nitro's PDF Reader) and check for updates to the software reviewed in our previous survey.

The big news, of course, is the release of Adobe's Reader X, the 10th generation PDF viewer from the company that started it all. Reader X is a significant improvement, including new (from Adobe) features previously reserved for the paid Adobe Acrobat. It's not an idle move on Adobe's part - the competition is accelerating.

I've discussed this issue of "bloatware" before, and thus won't dwell on it too much this time. Simply put, one need not worry whether ABC software has a 5 MB or a 50 MB installer, or takes 20 or 200 MB of HD space, or consumes 30 or 50 or 100 MB of RAM when running.

Safari and Netscape readily soak up 500 MB of RAM at the drop of a hat, 5x more memory than the 'heaviest' PDF Reader on its worst day. Bottom line: the only thing worth ranting about is performance.

How we reviewed, what we looked for

The selection of Readers is not intended to be definitive. We are open to adding new PDF viewers as they become available. If you feel we're missing an important new option, please feel free to leave a comment, and we'll consider it for the next review.

As in the previous round-up, we're not focusing on marquee features decorating various marketing materials. This review focuses on real-world performance in key line-of-business functions. The point is to find out whether or not these applications were ready for prime time, comparing them to the application that remains the de facto standard for PDF viewing: Adobe's Reader.

All tests were performed on Windows XP. This may seem slightly "retro", but the reality is that Windows XP is still far-and-away the most commonplace desktop operating system right now - and performance in the real-world is what this review is all about.

Comments

Safari and Netscape readily soak up 500 MB of RAM at the drop of a hat dvd, 5x more memory than the 'heaviest' PDF Reader on its worst day. Bottom line: the only thing worth ranting about is performance.

Nitro PDF takes themselfes out of the running with their new ribon. Why do developers fail to "get it" that the vast majority of users DO NOT want this non-intuitive, screen wasting ribon format?

So, I guess my case is confirmed? ;-)

> Where? Are you saying Acrobat renders the shape incorrectly? Can you please provide a PDF that demonstrates where Acrobat does not properly implement the spec?

There is such file: http://www.dreamsoft-sg.com/socrat/highlight.pdf

You can easy create your own - just add highlight comment to any document and check /QuadPoints array of this comment when document will be saved.

> On the issue of the form DOM, that is an implementation detail and not a specific part of the spec.

Understood, and it is a point I have complained in my first post - there are a lot of such PDFs, and as result these PDF cannot be handled by non-Adobe products.

>Adobe Acrobat uses different order of points in quads

Where? Are you saying Acrobat renders the shape incorrectly? Can you please provide a PDF that demonstrates where Acrobat does not properly implement the spec?

On the issue of the form DOM, that is an implementation detail and not a specific part of the spec.

About XFA and form DOM. Let say we have field in XFA:

When you fill this field, this data is stored in form DOM in run-time. But, when you save this document, where data should be stored? Adobe Acrobat saves form DOM in XDP. Agree, this behavior conforms to the specification (“However some XFA applications may save a copy of all or part of the Form DOM in order to preserve the context of a session”), but in the specification the format of form DOM in XDP is not described.

You wrote:

QuadPoints, as used by annotations, are fully documented in ISO 32000-1 and implemented as such in Acrobat/Reader

No, it is not. As documented in ISO spec, the order of points in quad should be oriented "in counterclockwise order" (table 179 in section 12.5.6.10). But, Adobe Acrobat uses different order of points in quads - like letter Z: left-top, right-top, left-bottom, right-bottom point. So, it is by specification, isn't ?

to the "unknown guest"...

You write:

I would like to say some non pleasant words about Adobe Acrobat: even if PDF and XFA supposed to be open standard, and all developers are oriented on what Adobe Acrobat/Reader supports, but not what described in PDF specification.

I don't understand what you mean. PDF is an open standard - it's ISO 32000-1 - and that standard incorporates not only file format requirements but also reader behavior as well. That behavior is, for (obvious) practical reasons based on the implementation of Adobe's products. So if you implement the standard, that's great.

Admittedly, Adobe Acrobat & Reader also have some application-specification functionality as well that are not part of the standard. Of those, only Adobe's JavaScript language extensions are referred to by this article. So is that what you refer to??

You also wrote:

Some examples: a) order of quads' points in text markup annotations (highlight, strikeout, underline) - in PDF specification, and in Adobe's implementation this order is absolutely different; b) XFA forms (static and dynamic) and Form DOM - Adobe Acrobat stores Form DOM in XDP and in this DOM data for fields with <bind match="none"/> are stored.

QuadPoints, as used by annotations, are fully documented in ISO 32000-1 and implemented as such in Acrobat/Reader. In what way are they "different"? Are you, again, referring to something such as our JavaScript extensions?

I don't understand your point about the binding element. Are you saying this particular element is used by not documented? What??!

Leonard Rosenthol
PDF Architect
Adobe Systems

There are a lot of such small tricks.

John:

a) What's the problem with preloading? Adobe Reader's not exactly the first software (or the only PDF Reader software) to do it.

b) Yes, preloading appears to consume an additional 3 MB of RAM, waiting for Reader to start. For the vast majority of users, this is insignificant. (but I did just add those 3 MB to Adobe's RAM consumption in the table).

What else am I missing?

Peter:

Thanks for the note. I did address the question of whether the Reader supports tagged PDF. As to working with AT... if they don't support tags, there's not much point in supporting assistive technology, is there? I'd like to see more attention to that issue all around.

Duff.

Duff, if you look at the settings for how Reader preloads, by the time you've gotten to the desktop, all startup items have executed.

Duff

Thanks for the update review.

One test you missed out is how the readers work with Assistive Technologies e.g. screen readers and magnifiers.

I assume the answer is only Adobe Reader on WIndows works, is that correct?

On Mac the situation is odd:

Preview works well with VoiceOver, if all you want to do is read the text, but does not recognise the Tags so does provide an y function for navigating and does not read alt text.
Adobe Reader does not work with VoiceOver.

This means that there is no good accessible way to read PDF on Mac.

John, the "Cold Start" timing tests in each case began with a system restart, as is indicated in my write-up of the "Performance" tests. Pre-loading was thereby removed as a factor from this particular test (unless you are suggesting that Adobe Reader pre-loads when I start the system, which I don't believe is the case).

The "warm start" tests, however, do include whatever pre-loading is going on, since in those tests I simply closed the app and then re-started it without also performing a full system shutdown.

The problem is, if you're comparing cold start times, then if you don't disable that partial load, you're really not comparing cold start. You're comparing a hot start to cold starts.

George - your comment's much appreciated, thanks. I will consider adding Preview in the next update to this survey... including an update on whether or not Apple have chosen to make behave properly.

As to testing flip speed... I considered it, but thought otherwise because it's so dependent (or so I imagine) on the graphics processor and the hardware generally.

John: I think the test you're thinking of is represented in the "cold start" data. That was my intention, certainly.

That said, if Adobe finds ways to spiff up performance... and if they actually work without causing notable reductions in performance elsewhere, then I say, more power to 'em!

Thanks for the correction on Foxit.

Did you make sure to disable any preloading of components? That's something Adobe loves to do as a way to spiff up performance, and they're still doing it with AcroX. (Just checked on a fresh install.)

Also, Foxit reader is not windows only: http://www.foxitsoftware.com/downloads/index.php

Very nice article, Duff. I understand (and agree with!) your reasons for not including Preview, but it would have been nice to include it at least for the starting and opening a file tests. Another test to consider adding is one to measure the time for moving through the document page by page from beginning to end, though this is likely difficult to properly measure.

Thanks for the suggestion - I'll bear that in mind for the next review.

The article does not seem to does not seem to involve the security feature and corporate deployments and upgrades .For example ，ASLR & DEP support and MSI for enterprise deployments.

PDF Document Management Software, Services & Support

The Latest

REVIEW: 5 Free PDF Readers Compared

Time for a fresh look

Bloatware? Really?

Demand "ISO 32000 conformance"

How we reviewed, what we looked for

Comments