Creating static named destinations in PDF using DITA XML and FrameMaker publishing

[Patrick_Porter]

Hello,

How to I create a named destination in my source DITA XML so that when FrameMaker publishes the PDF the named destination is unchanged from the DITA?

I am trying to create an xref in one DITA document that gets published to PDF (call it document1.pdf) where it creates a hyperlink to a relative path such as ../folder/document2.pdf#named_destination.

I cannot find any documentation for how to do this.

If I open document2.pdf and edit the named destination, when I click on the hyperlink in document1, it opens to that specific page in document2.pdf, but it is impractical to manually edit all of the named destinations in the target PDF.

Thank you!

Pat

[Bob_Niland]

As far as I know, it still takes an aftermarket tool to do that, such as the MicroType TimeSavers.

[frameexpert]

TimeSavers is a great tool that I have used with many clients over the years. However, TimeSavers is actually a Distiller add-on so you have to use Distiller when making PDFs from FrameMaker. This bypasses FrameMakers new print/PDF engine that was added in FrameMaker 2019 and therefore is a lot slower.

[Patrick_Porter]

Hi Rick! As you know, we don't want to go down that route given the workflow for our flight manual publish process. See the e-mail I sent you this morning...maybe you can jsx this?

I'm just surprised that FrameMaker can't do this...or that it adds the "extra" XY.newlink string to the named destination. Seems like shooting itself in the foot. Maybe there is a great reason why it does it, but I can't see it.
Pat

[frameexpert]

Hi Pat! It does that because it wants to ensure that the gotolink/newlink strings are unique throughout a book file. A FrameMaker book is essentially a pointer to bunch of independent FrameMaker documents. If you happened to have duplicate gotolink/newlink strings in multiple files in the book, the resulting PDF links would be a problem. So FrameMaker "helps" by appending a unique string to the font of each string. I would have to look, but I am pretty sure its something like M8.5.original-string, where M8 is the internal marker type name, 5 is the file's position in the book, and original-string is what you used for the newlink marker.

[frameexpert]

The older PDF engine made a Postscript file from the FrameMaker document, which was then run through Distiller. Since a Postscript file is (usually) a plain text file, TimeSavers was able to preprocess the file and manipulate it before Distiller got it. It was also able to do some post-processing after going through Distiller. It was quite elegant and powerful.

I don't know what Adobe is using new for its PDF library, but bookmarks, linking, etc., still work. I have been lobbying them to add ways to add PDF features in FrameMaker like you could do previously with TimeSavers and Postscript text frames. They did add a way to add page cropping to fulfill a particular client's AEM/FMPS workflow.

[Patrick_Porter]

Got it. Makes sense that they would want to ensure it is unique. Competing requirements it seems.

Given all that, I wonder if you could script a solution whereby we use a specific attribute in the DITA with a specific value prefix like "newlink_abcdef". The script would test for newlink_ and then use only the string after the _ and the newlink in the PDF is abcdef only?

Pat

[Patrick_Porter]

Hi Rick, so when I tried it yesterday during our call on the test files, it worked by having both FM books open. I tried it on a production AFM and OM yesterday and I got all the pre-oended 'X.Y.newlink' stuff. I have no idead why it worked in the first case but not in the second. And here I had declared victory prematurely!

[Patrick_Porter]

OK, the "keep both FrameMaker books open at the same time" definitively does not work. The reason it "appeared to work" yesterday was because when I ran the publish live, I named the file the same name as the one that I had manually edited the named destination. Adobe PDF has this NASTY habit of opening earlier versions of PDFs if the files have the same name. They get stuck in a cache somewhere. We have experienced this before...it is REALLY BAD. So, I just changed the href values and changed the file names in the source DITA, re-ran the publish on both, then saved as PDF. The newly created target document had the X.Y.newlink pre-pended. That definitely proves this technique won't work. There HAS to be a way!!