Hi Pam,

Not sure what might be wrong (if anything) with your DEST and 2DEST coding of the pdfmark macros, but I would eliminate making any changes to the Action section of the PDF Support spec (just in case this is the source of the "OffendingCommand" error when you distill). As far as what you entered in the PDF Support spec for the GoToR and Launch actions, instead of just entering the value "pdfname.pdf" I think you would need to enter "(pdfname.pdf)" as in PostScript the parentheses are needed when you have a "string" value. I think this problem might be the source of the "OffendingCommand" error you are seeing when you distill.

As stated in the documentation, the Action in the PDF Support spec "specifies an action to perform when the PDF document opens in a PDF viewer." In my experience with looking at customer samples, it would be fairly unusual to see the specific GoToR or Launch actions from the PDF Support spec used (because of what they do). 

So, the Actions are meant for defining an action that the PDF viewer performs as soon as you open the PDF and that's not what you are trying to do with the 2DEST and DEST pdfmark macros. If I understand correctly, for what you are trying to do all you need are the DEST and 2DEST pdfmark macros.

Eliminate the PDF Support spec changes (or fix the missing parentheses) and then where are you? Do you still get an error when you distill?

I don't see anything wrong with your DEST and 2DEST pdfmark macros, but you've not given the "exact" coding you are using (seems more like excerpts from the documentation).

One thing you need for sure is to be using the same exact dest-name in the DEST and 2DEST macros (the argument right after DEST/2DEST).

We do successfully use the DEST and 2DEST pdfmark macros in our XPP documentation (the divisions are in Classic Mode).

Here is an example. On page 3-7 of xypdf.pdf we have:
<:pdfs;DEST;PDFMACROSBYTYPE>1<:pdfe;DEST>
and on page 2-305 of cmdutils.pdf we have:
<:pdfs;2DEST;PDFMACROSBYTYPE;/File (xypdf.pdf) /Color [1 .5 0]><mdit>XML Professional Publisher: PDF Support in XPP<med><:pdfe;2DEST>

The "/Color [1 .5 0]" added to the 2DEST optional data produces an orange box around the hot link.

Note: Unless you're specifying other optional data in the pdfmark macros, whether the box around a hot link is visible (non-zero width) or not is controlled by the last three fields in the PDF Support spec.

Hi Pam,

Not sure what might be wrong (if anything) with your DEST and 2DEST coding of the pdfmark macros, but I would eliminate making any changes to the Action section of the PDF Support spec (just in case this is the source of the "OffendingCommand" error when you distill). As far as what you entered in the PDF Support spec for the GoToR and Launch actions, instead of just entering the value "pdfname.pdf" I think you would need to enter "(pdfname.pdf)" as in PostScript the parentheses are needed when you have a "string" value. I think this problem might be the source of the "OffendingCommand" error you are seeing when you distill.

As stated in the documentation, the Action in the PDF Support spec "specifies an action to perform when the PDF document opens in a PDF viewer." In my experience with looking at customer samples, it would be fairly unusual to see the specific GoToR or Launch actions from the PDF Support spec used (because of what they do). 

So, the Actions are meant for defining an action that the PDF viewer performs as soon as you open the PDF and that's not what you are trying to do with the 2DEST and DEST pdfmark macros. If I understand correctly, for what you are trying to do all you need are the DEST and 2DEST pdfmark macros.

Eliminate the PDF Support spec changes (or fix the missing parentheses) and then where are you? Do you still get an error when you distill?

I don't see anything wrong with your DEST and 2DEST pdfmark macros, but you've not given the "exact" coding you are using (seems more like excerpts from the documentation).

One thing you need for sure is to be using the same exact dest-name in the DEST and 2DEST macros (the argument right after DEST/2DEST).

We do successfully use the DEST and 2DEST pdfmark macros in our XPP documentation (the divisions are in Classic Mode).

Here is an example. On page 3-7 of xypdf.pdf we have:
<:pdfs;DEST;PDFMACROSBYTYPE>1<:pdfe;DEST>
and on page 2-305 of cmdutils.pdf we have:
<:pdfs;2DEST;PDFMACROSBYTYPE;/File (xypdf.pdf) /Color [1 .5 0]><mdit>XML Professional Publisher: PDF Support in XPP<med><:pdfe;2DEST>

The "/Color [1 .5 0]" added to the 2DEST optional data produces an orange box around the hot link.

Note: Unless you're specifying other optional data in the pdfmark macros, whether the box around a hot link is visible (non-zero width) or not is controlled by the last three fields in the PDF Support spec.

Thank you both Bart and Jonathan for your responses.

I will go back and try your suggestions and get back with you on my results.

I have been able to get the DEST and 2DEST coding to work for me. When I click on the link to open up another PDF, it doesn't open up in a new tab in acrobat. It just switches back and forth in the same tab. I also have my Acrobat preferences set to open in new tab. Also, I've added the following information to my 2DEST xymacro:

<:pdfs;2DEST;named-dest;/File (named-dest.pdf) /NewWindow true>

Thank you for any information in advance.

I have never found a reliable "setting" that gets Acrobat to consistently open up another PDF in the same tab or a new tab.

I do not see /NewWindow listed as a valid distiller parameter in the Ghostscript documentation, which might be why that did not help.

I have just always found that in Acrobat, whatever I am getting for the same tab versus new tab behavior if I Control-click instead on a link then I get the opposite behavior.

Maybe that will help.

Actually, let me revise what I said.

What I have found with Acrobat with the scenario you are talking about (cross-document links in a PDF) is that the same tab versus new tab behavior is controlled by an Acrobat Preference setting, which appears to override any other attempt to control what happens.

In Acrobat go to Edit > Preferences > Documents > Open Settings section > Open cross-document links in same window checkbox

There is also another related Preference setting (at least I think it is related):
Edit > Preferences > General > Basic Tools section > Open documents as new tabs in same window (requires relaunch) checkbox

I am not sure exactly how these two Preference settings interact.

I mentioned it already, but whatever same tab (or window) versus new tab (or window) behavior occurs with a click (by the Preference settings) - Control-click should give you the opposite behavior.

Thank you so much Jonathan. It was the Open cross-document links in same window checkbox. It is working how we want now.

Once again. Thank you for all the help.