Hyperlinks don't work with Reader 9 with PDF/a

[_Dan_Schultz_]

Reader 8 and below in PDF/a mode with hyperlinks works just fine.. Upgrade to 9 and say good by to working hyperlinks! I would disable PDF/a mode but then Excel will not embed some of my type 1 fonts... Word gives the option to convert to bitmap if it can't embed... Why did Adobe change Reader v 9 to disable hyperlinks in PDF/a documents!!! they should have left it alone.. help anyone?

[AbhigyanModi]

That is because Reader 9 renders content conforming to pdf/a specifications. The specification prohibits compliant viewer from allowing interactive content such as links (the logic is that the document should be self contained - who knows the state of the link when your archived document is read 100 years from now :-).

You can turn the PDF/A view mode off in preferences - Documents>PDF/A view mode>Never.

[KazuTakeda]

Great answer. Thanks!

[poisson02]

The following worked for me:

$ acroread -version

9.5.5

on a GNU/Linux OS.

Go to

Edit>Preferences>Trust Manager>Change Settings...

and, on the Manage Internet Access panel, tick

* Let me specify a list of allowed and blocked we sites

(default)

* Allow access

(default: Always ask)

It looks like the default should allow to follow the hyperlinks and launch the browser but it does not for me...

[_Leonard_Rosenthol_]

Abhigyan is 100% on the mark with his response.

The PDF/A standard (ISO 19005-1) clearly states in section 6.6.3:
>Conforming interactive readers may choose to make hyperlinks >non-actionable, but in addition to the rendering behaviour defined by
>PDF Reference, as modified by this part of ISO 19005, they shall >provide a mechanism to display the F and D keys of a GoToR action >dictionary, the URI key of a URI action dictionary,
>and the F key of a SubmitForm action dictionary.

As such, Adobe Acrobat & Reader 9 are simply following the rules as defined in that standard.

In addition to that requirement, there are about another 10 requirements for "conforming readers" laid out in the standard - all of which are ONLY ENABLED when you have the "PDF/A View Mode" option set to "When documents are compliant with PDF/A"...again, as required by the standard. IF you turn that option to Never, you are no longer in compliance with PDF/A :(.

Leonard Rosenthol
ISO Project Leader/Editor - PDF/A (ISO 19005)

[R_Bornheim]

Hello!

If Hyperlinks are not allowed at all in PDF/A then i wonder why Hyperlinks of "HTTP://..." are working in PDF/A documents created from Word with Adobe 9.1.3 Pro but Hyperlinks of "DDD://..". are removed from the PDF file.

Adobe implement something that seems to me to be not consistent.

I double checked your statement regarding the PDF/A standard with someone of the PDF/A commitee attendants.

The response was that removing Hyperlinks has nothing to do with the PDF/A standard.

The relevant standard chapter is:

...

6.5.3 Handling of GoToR, URI and SubmitForm Actions

While permitted to be present in a conforming file, there are three types of actions for which a conforming interactive reader shall provide special treatment – the GoToR, the URI and the SubmitForm actions. The conforming interactive reader shall provide a mechanism to display the F and D keys of a GoToR action dictionary, the URI key of a URI action dictionary, and the F key of a SubmitForm action dictionary.

In addition, since the actual invocation of these three actions by a conforming interactive readers involves the locating of and interacting with other files that may or may not be conforming, the reader may choose to not allow the actual invocation of these actions.

NOTE For purposes of archival disclosure of the complete information content of conforming files, it is important for interactive readers to provide some mechanism to expose the destination of such actions. However, this part of ISO 19005 does not prescribe any specific behaviour or the technical implementation details that interactive readers might use to meet these functional requirements.

...

I would suggest to clarify the PDF/A standard and improve your current implementation.

Best wishes,

R.Bornheim.

[AlexAKuzin]

This solution does not work.

What happens is links do not work inside of the actual Adobe Reader 9.0.  But they DO work if viewed inside of either IE or Firefox Adobe Reader plug-ins, which are COM based and essentially call the same Adobe Reader 9.0 code base.  I do not understand the need for this difference in behavior.  The support wanted to charge me $40 to have this addressed, and again I do not see why, since this is clearly an Adobe Reader bug.

[_John_McFann_]

Sometimes I think designers of software and ISO standards authors are adversely affected by the rarefied atmosphere they operate in. For the other poor souls who are experiencing this problem and have finally stumbled onto this page after wasting a couple hours (or more) of their time trying to figure out why links in their PDF documents don't work anymore, the solution is:

A: Open your preferred browser. Reader 9.0 may not open it for you.
B: Open the "edit" menu, go to the bottom and click on "preferences."
C: At the top under "categories:" click on "documents."
D: Down at the bottom, under "PDF/A view mode," click on "never."
E: Click on "OK" to exit.

If that doesn't work, kill 9.0 and install an earlier version of Reader.

The rest of this is for the application developers and standards writers:

I'm all for standards when they promote uniformity between suppliers and usability. E-mail and PFD documents are supposed to promote fast, efficient cross platform communication. The logic that the document should be self contained is flawed and here's why; many e-mail providers and clients impose size limits on attachments as low as 4MB. It doesn't take too long to exceed that limit when the document is large and/or has a lot of graphics (especially photographs) included or, the author wants to direct the reader to necessary resources that are large and may also contain these things. Who cares if the links aren't valid a 100 years from now? The information in the source documents probably won't apply by then either!

Come on folks, don't make life more complicated for your customers and users.

[_paul_c_johnson_]

I had this same problem, so I just went back to 8

[_Claudio_Beccari_]

The problems set fort by the limitations of the standard ISO 19005-1 have advantages and disadvantages the former largely compensating the latter.
But the format PDF/1a or /1b is sort of new and many users don't even know their existence. At the same time Adobe does not make any effort, I would dare say, in spreading knowledge about these formats. If one wants to make a compliant PDF/a file s/he has to resort to Acrobat Pro 8 or later, or to other commercial programs. Some freeware programs can also produce compliant PDF/a files. But the real-actual compliance is not guaranteed; it depends on many unsuspected factors, and the produced file must be verified. This, as far as I know, is feasible only with the Preflight menu entry of Acrobat Pro 8 or later. Even conversion can be done with this Preflight entry.
Well, IMHO, I think that the Reader should contain a reduced form of Preflight so that, at least, it's possible to verify that a prospective PDF/a file is actually PDF/a and, possibly, why it is not compliant. The new feature of the Reader should be properly advertised and highlighted in the "new" Reader, so that all users of this software become more aware of this new format and know the details, the pros and cons.
I appreciate the Reader 9x exactly because it informs the user that s/he's reading a PDF/a; I would appreciate if it had means for verifying that it actualy is PDF/a (or PDF/b).