XPP Version 9.2.2.0 - Open PDF using PDF Xymacros

XPP Version 9.2.2.0

I am trying to open another PDF and go to a specific page using PDF macros DEST and 2DEST. I looked through the documentation and it did state that another document can be opened using 2DEST.

Below is the coding that I am using

In the PDF where coding is added using DEST, I am using the following PDF xymacros:

<:pdfs;DEST;destination-information>destination information<:pdfe;DEST>

In the PDF where coding is added using 2DEST, I am using the following PDF xymacros:

<:pdfs;2DEST;destination-information;/File (pdfname.pdf)>Text text text<:pdfe;2DEST>

I have also done the following in the PDF Support Spec:

Action GoToR

(GoToR) Destination pdfname.pdf

I have also tried the following in the PDF Support Spec:

Action Launch

(Launch) Document or App pdfname.pdf

I create my 2 .ps files and I am getting the following error when I try to distill the files:

%%[  Error: undefined; OffendingCommand: pdfname.pdf. ]%%

Stack:

/GotoR

/Action

/UseOutlines

/PageMode

-mark-

Any help is much appreciated.

emoji
  • All I can say that it should work with the 2DEST and DEST combination.
    I just created a small test and it does work without problems.
    Screenshot of Trados Studio with a Security Warning dialog box, indicating 'This document is trying to access: C:Tempfile2.pdf' with options to Allow or Block.

    I think the first thing for you to verify is if you see a little box around the 2DEST text.
    By default there will be a border around the text sitting between the start and end of 2DEST macro's.

    If you do not get a box, you might start to look at how you entered the :pdfs and :pdfe macro's.
    Because if you do not see a box, that means that the macro's are not recognized by XPP

    emoji


    Generated Image Alt-Text
    [edited by: Trados AI at 5:34 AM (GMT 0) on 5 Mar 2024]
  • 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.

    Jonathan Dagresta
    RWS Group/
    XPP Development

    emoji
  • Thank you for your response Bart.

    I am not able to see a box, because it won't create a PDF. It errors out while distilling.

    I have also checked the coding and it looks good. I don't know if it has something do do while creating the postscript and pdf.

    emoji
  • Try with an empty division like my sample.
    Just build it up part by part and print often.
    Just try the 2DEST macro and try if you can see the border.
    (it does not matter that the destination does not exist)
    Like that you will find out when it errors out.

    I think the most encouraging thing for you it to know is that it should work...

    emoji
  • 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.

    emoji
  • 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.

    emoji
  • 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.

    Jonathan Dagresta
    RWS Group/
    XPP Development

    emoji
  • 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.

    Jonathan Dagresta
    RWS Group/
    XPP Development

    emoji
  • 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.

    emoji