I don't think this can be done if you can't edit the PDF files.
We are looking here at a rather big project.
One possibility would set up a system to run through the documents, and add appropriate links or fields at the places. For new documents, this would happen when they get checked in at the DMS. For legacy documents, it would be quite a bit of work to catch up. Acrobat would not be powerful enough to do it. You might have a talk with Appligent whether any of their tools could be used to do it.
The other possibility would be twist Adobe's arms to get a decent deal for either fully upgrade all users to Acrobat Pro, or at least Acrobat Standard. From my experience in the past, such volumes may be negociable.
It would be a question of cost (investment and labor) to decide between these two directions.
try67, Thanks for your consideration.
Max, Thanks for the options.
Unfortunately, neither is viable, the first because the PDFs may not be modified (as a records retention standard, we do not allow links or code in records), and the second due to budgetary constraint (we already have a substantial site license discount.
I told the boss I guessed there was a 50% chance of finding a solution. If I can't find a solution, perhaps plan B (automating Acrobat to recognize hyphenated words, and launch them as part of an url) will work for the 50% of our users with Acrobat; that's still a lot fewer headaches each year.
Still looking ...
The problem is that something needs to trigger this action, and that
something needs to be inside your PDF. You might want to post this question
over at the Acrobat SDK forum. Maybe this could be achieved with a plugin
instead of a script.
1 person found this helpful
I thought so (about the documents not being modifiable; I am not sure about the developments in PDF/A, but it may be that the very newest standard would allow for active elements.
This leads to a few further possibilities.
a) what if your DMS would have a delivery service, automagically adding the active elements at delivery time? So, the end user would not receive the archived document, but a document, enhanced at runtime. You might also add some more features in that process, such as a livespan or so. Depending on the features you want to add, you might need an ARES with appropriate licence. To follow this line of thought, I would talk to Appligent and Adobe.
b) using a plug-in. What you require should be feasible. The big issue here is that the plug-in would require a Reader key, costing an unknown amount. On the other hand, as it would be limited (have to be limited) to your organization, there should be some negociation leeway. For the Reader key you will have to talk to Adobe, there is no way around it.
c) replace Reader with another PDF viewer which would allow what you want. A volume licence of that other viewer would have to be taken in consideration. It most likely would be lower than a volume licence for Acrobat Standard.
You would have to carefully specify what you need, and then decide on the feedback you get.
Thanks again for giving me so much of your time and consideration.
It's becoming clear that the answer to my unstated root question was the first line of your first message ...
"We are looking here at a rather big project."
I was hoping to throw together an add-in with a handful of my hours. It appears that this might be a realistic estimate for Acrobat, but for Reader the cost is realistically 2 orders of magnitude higher than that. I won't be able to sell this.
I think the point of PDF/A is that there IS no new development. :-> ... besides, if we embed the link to a doc where it sits now, that link dies the minute the record is removed from our environment, we replace the DMS, change the path to the web service that returns the records, or turn over the records to the customer for archival ... for 60 years or more ... hence, no content in PDF/A that is dependent on external resources. The record number is the only part that endures.
a) I had dismissed this because of the cost of the DMS integration ... and politics ... I sit in the records organization, providing end-user tools (mostly client-side), not in IT (who manage the DMS). However, you've got me rethinking the middleman approach ... I already have a pair of popular tools that circumvent the laborious process of looking up a doc in the DMS, one is an Excel add-in that adds a context menu option to do a DMS lookup based upon the content of the clicked cell, and the other is a hotkey-launched query that accepts nothing but a doc number and does the lookup. These share a common web service to do the DMS lookup without the overhead of the DMS frontend. I could hook either the client or server side. It still leaves me with a gap ... how to cheaply enhance the PDF. I suspect IAC has similar limitations for Reader. I suppose it's time to look at pdftk and its ilk. (BTW, what do you mean by "livespan"?)
b) I considered a plug-in, but ruled it out due to the learning curves for me ... both the Acrobat API and a new language and development environment. I was not aware of the need for a Reader key ... yet another straw for the camel's back. Perhaps plug-in development will be one of my "career development" goals for the next year.
c) I'm considering this option. We have a site license for Neevia docuPrinter Pro. We currently just have the printer driver deployed, giving Reader users the ability to create PDFs, but IT is considering deploying the "desktop" in an attempt to reduce the number of Acrobat licenses for users who just need to insert pages in PDFs. I know it can be automated, but I don't know if it has what I need.
Unless someone surprises me, it looks like I'll be providing the tool just for Acrobat users for now.