A

Anonymous

Answered

How to extract the list of named destinations

Forum|Forum|9 years ago
January 18, 2017
1 reply
6128 views

My team produces a software product with PDF help. We create the PDF help in InDesign and use javascript to create automatic named destinations from the table of contents to be able to open the pdf help to specific locations from our program.

For some reason, InDesign attaches some random digits to the end of all of our named destinations. They are not visible in the named destination list in InDesign, but when you export the pdf, they appear. From what I can gather online, this is a new problem introduced in Creative Cloud 6 but I don't see any responses from Adobe regarding them acknowledging or fixing this problem. Can you please address this?

As a work around, my team would like to deal with these random digits by extracting the list of named destinations from the pdf so we can link to them appropriately. I see this question asked many times with no actual answers/help provided. They say "use the sdk; it has examples."

I downloaded the SDK and have been going through the documentation and there are no examples for this. It's very confusing because the documentation describes the file trailer and document catalog and name trees but the actual Acrobat TLB does not seem to have corresponding parameters/functions to access these.

Please, please, please, can someone from adobe provide some help in how to extract the named destinations? This is a very big issue for my team and I think many other individuals.

Acrobat SDK and JavaScript

This topic has been closed for replies.

Correct answer Test Screen Name

The full PDF structure is only available to plugins, in C/C++, which can use the Cos later to examine specific objects. Though a PDNameTree API might be more simple for the named destinations. The other APIs only offer packaged access to a tiny fraction of the PDF content; and the ability to write does not mean there's an ability to read.

T

Test Screen NameCorrect answer

Legend

The full PDF structure is only available to plugins, in C/C++, which can use the Cos later to examine specific objects. Though a PDNameTree API might be more simple for the named destinations. The other APIs only offer packaged access to a tiny fraction of the PDF content; and the ability to write does not mean there's an ability to read.

lrosenth

Adobe Employee

As TSN says, you will need to write a plugin in C/C++ to get this info and the PDNameTree APIs (along with some Cos APIs) will achieve your goals.

Karl Heinz Kremer

Community Expert

Thank you very much for that book suggestion! I will definitely get my hands on a copy. Could I please follow up with a few more questions?

1) In absence of the app wizard, how would you compile it specifically to a .api file? That stands for adobe/acrobat plug in file, right? So how does Visual Studio produce that output type without some kind of plug-in or tool provided by adobe?

2) Should it have been inherently obvious to me that I should look at the snippet runner? I can't seem to find any kind of "meta" documentation explaining what the different sample projects attempt to accomplish. So I have been randomly looking at different examples and the name "snippet runner" didn't mean much to me so I didn't even look at it until you mentioned it.

3) I apologize, I haven't done any kind of large scale cpp project, so I'm a bit confused on how to pull in these examples. From reading the plugin introduction site, I think I need some of the headers in the Acrobat XI SDK\PluginSupport\Headers folder for some of the handshaking. But that folder is provided separate, outside of the samples directory, so am I incorrect about that? I'm just surprised those headers aren't a part of each of the sample projects given.

4) So if I wanted to look at the sample snippet runner could I just copy the entire Snippet Runner directory into my working visual studio directory and then just open the .sln file? Are the sample projects and directory setup such that everything is where visual studio would look for the associated .cpp and .h files?

I realize that I sound a little ridiculous asking some of these. You're probably wondering "why don't you just try it and see if you can get it to work yourself?" The thing is, I'm waiting for my system admins to approve putting the adobe sdk on our network, so right now I'm unable to do anything and don't want to waste even more time later. So I figure if I get my bearings straight now, I can just get straight to work when I finally have the sdk available to me.

Thanks!

#1 When you use one of the sample projects, they come with the project configuration files correctly set up to produce API files. Which means that when you copy and modify one of these projects, you automatically get these project configuration files as well, and your new project will (or should) also create an API file.

#2 The snipper runner will be a bit too much information for you if you have not yet compiled your first plug-in yet. The names of the plug-ins (with probably the exception of the snippet runner) will tell you what the plug-in does:

BasicPlugin - very basic plug-in

BatesNumbering - apply "Bates Numbers" do a document

DMSIntegration - integration with a document management system

DocSign - sign a document

Embed3dData - just as the name implies, embed 3D data in a PDF file

PDFBinder - create a PDF Binder or a PDF Portfolio

RplcFileSystem - Create and use a new filesystem

SelectionServer - create a selection server

ShowPermissions - show the permissions of the document

SnippetRunner - Display and run many different code snippets from all over the plug-in API

Stamper - place a stamp

Starter - Use this as the "starter" for our own plug-in

UncompressPDF - Uncompress compressed information in a PDF file

WeblinkDemo - Creates and regisgers a new weblink driver

wxPlugin - Uses a wxWidgets user interface

The description of what a plug-in does is usually in a comment in the first few lines of the corresponding "Init" file (e.g. WeblinkDemoInit.cpp for the WebLinkDemo plug-in).

#3 Yes, the headers are outside of the sample project folders - because they are used for all projects. This is the normal way of setting up C/C++ projects, where you include (link) external resources. All you should have to do is to open one of the project files (e.g. BasicPlugin.sln in PluginSupport\Samples\BasicPlugin\win32), and VS should do the rest.

#4 You need do copy not just the actual project directory, but also the Headers directory, and the Headers directory needs to be in the same relative location as it is in the SDK folder. What's easiest is to just develop right in the SDK folder, and create a folder named "MyPlugIns" right next to the "Samples" folder, then copy whatever plug-in you want to play with from Samples to MyPlugIns - this way, all the relative links are still working, and you don't have to "mess" with the project configuration.

Hope that helps.

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.