PDF Bookmarks no longer useful after changing to Structured FM (FM2019)

[QuintinSeegers]

We previously used Unstructured FrameMaker. Our Table of Content was generated using Paragraph Styles. Whenever we converted our documents to PDF and opened the PDF in Acrobat Reader, the bookmarks appeared like this:

Clicking on the bookmark would take you to the corresponding page in the document.

We have since moved to Structured FrameMaker. Our Table of Content is now based on Element tags instead. When we convert our documents to PDF and open the PDF in Acrobat Reader, the bookmarks appear like this:

Clicking on any of the bookmarks takes you to the location in the Table of Content, not the corresponding content page in the document. (Incidentally, clickin on the topic in the Table of Content does take you to the corresponding content page in the document.)

We are creating PDFs using the Save as PDF option. (Don't like that using Publish option because it creates a sub-folder in our selected destination folder to save the generated PDF file to, rather than saving it to our selected destination folder.)

[frameexpert]

You can use Format > Document > PDF Setup to set which elements appear as bookmarks. You should be able to do this a the book level as well.

Also, if you EDD calls paragraph formats in your template, you can still use paragraph formats as your bookmarks. In the PDF Setup dialog box, just choose Paragraphs from the Bookmark Source dropdown list.

[QuintinSeegers]

I did not know about the PDF Setup (embarrasing to admit for a 10+ years FM user!). Will definately look into that. Can this be set up as a Default?

[frameexpert]

This is a document property so it should be preserved when you save the document.

[QuintinSeegers]

After changing the PDF Setup to the following:

bookmars are still not appearing/functioning correctly. Previously the bookmarks listed the topics in the correct hierachical structure, each bookmark directing to the corresponding page in the content. Now it's just a flat list of topics (instead of the hierarchical Element structure) that redirects back to the topic listing in the Table of Content, not the corresponding page in the document.

[Winfried Reng]

Hi,

I do not know about the setup in structured FrameMaker. Obviously these buttons to change the hierarchy are only available for paragraphs, but not for elements.

In Bookmark source you should select paragraphs instead of elements (as Rick suggested). Then you will get these buttons below the paragraph list.

Best regards

Winfried

[QuintinSeegers]

The only Paragraph Styles we have are those used for the Table of Content, and some static text on our master pages. All other formatting is determined by the Elements. (We've gone this route because some of our writers have a tendancy to overwrite the styles and therefore not comply with our design guidelines.)

I'll have a bit more of a play to see if I can get some sort of acceptable result.

[4everJang]

I have done tons of projects where customers moved to DITA (or other structures) and I always used the Paragraph and Character formats to allow customers to make changes to the styles without changing the EDD (where non-savvy users can break more than I want to fix). I did make it clear to those customers that they needed to have one or two style guide masters and nobody else should even try to make style changes to the templates (handled easily by only giving access to the templates to those who own the Style Guide in the first place).

The problem of authors overwriting styles should be fixed in a different place and manner. One is saving all your structured content to XML. That causes the template to be re-applied whenever the XML is re-opened. Another option is removing the Paragraph and Character Designer from the menus of the authors who are not supposed to make changes to the styling. In that case you could keep saving structured FM to FM binary format. I prefer the first method as that is fail-safe and also allows you to make changes (corrections ?) to the style guide without having to import the changed template into each and every FM binary file afterwards.

[Winfried Reng]

Your screenshot indicates that there are two paragraphs or elements for the PDF bookmarks.

And when the bookmarks take you to the TOC, then the wrong paragraphs or elements are selected.

Rick told you how to change this in the PDF Setup.

Yes. You can use this as default when you use this book as basis for others, but a change in one book will not change this in other existing books.

I have a template book (with title, copyright, TOC, some default content files, index, back) in which everything is set up correctly. Just change this in your template.

[QuintinSeegers]

We, too, use a template book with default documents/settings, so it will work for new manuals. Unfortunately, it looks like we will need to manually update the PDF settings on our existing training manuals. Fortunately we are going through a rebranding process, so all our training materials have to undergo a review, so I can use this opportunity to fix the PDF settings in our existing manuals.

[JonBe]

Hi Quintin,

You have had lots of good advice that will hopefully help!

Bookmarks, sigh! I have spent considerable time over the last several years with bookmarks for structured books. The first issue was that when a customer moved from unstructured, where the number and heading were one paragraph style, to a //no and //heading element with different styles, bookmarks were initially dropped. Then consumers of the PDFs complained, so I wrote code that post processed the bookmarks using Acrobat Pro via a COM interface, to produce the expected, clickable links. Now when I come across PDFs without bookmarks, it is phiff, why not provide them!

So a bookmark goes from 

to

The other issue I have had is that the book file seems to retain information about paragraph styles that gets imported when the components are added. A problem with this surfaced with FrameMaker 2019, where a incorrect bookmark style would get used, despite going through the PDF properties for the book and all of the components and setting them correctly. In the end, I created an Extendscript to run over all the document templates to set DocAcrobatElements to the desired elements and iterate over all the paragraph styles to set AcrobatLevel and PDFStructureLevel as required. Then updating the associated book allowed bookmarks to be generated correctly.

As you can see I both love and loathe bookmarks!

Good luck!

Jon

[frameexpert]

On another note: Adobe delivered a brand new PDF engine with the FrameMaker 2019 release. It is no longer PostScript based so they eliminated the ability to use PostScript text frames. (They put a legacy "Use Acrobat Distiller" setting in the Publish panel; see the screenshot.)

I had written several scripts for clients that built custom bookmarks and put the bookmark code in a PostScript textframe. That ability is now gone unless the setting above is used. I argued against this during the pre-release and I had to demo the usefulness of PostScript text frames to the engineering team.

Of course, the new PDF engine has the ability to add bookmarks by some internal method and Adobe should expose it somehow to the FDK/ExtendScript (and by extension, FrameScript). They have already done so with page cropping, which I won't detail here.

[JonBe]

Thanks Rick,

I never clocked the change as we were always going to use Distiller, so it was always set. I never really liked the Publish concept, tho I guess it ties together other ways to output from FrameMaker.

I think it would be a lot easier if Adobe exposed ways of generating bookmarks that provide more flexibility than the current single element or paragraph style approach. Not everyone has Acrobat Pro installed to use the COM based approach I used, or the coding skills/experience.

Jon

[QuintinSeegers]

We use the Save as PDF option from the file menu. We found using the Publish option creates an additional subfolder for the PDF, instead of creating it in the selected folder, i.e. if you select the path C:\Distribution\Manual\PDF and the document is called 'Typing', it creates a subfolder called Typing in the PDF folder (thus C:\Distribution\Manual\PDF\Typing) and saves the PDF in this folder, instead of the originally selected folder. This means we constantly have to move the PDF to the correct folder and delete the redundant folder.

[QuintinSeegers]

@JonBe 

We ended up removing the bookmarks because they're a complete mess with Structured FM using Elements. We deliberately made the decision to remove the paragraph styles and use FormatChangeLists in our EDD because some of our writers like to format things 'their way' and not comply with our corporate style guide, so using Paragraph Styles fore the Table of Content is not an option anymore.

I'm completely unfamiliar with writing scripts for FM (and am hesitant to do so). Getting someone external to write one for us, or to purchase one from a developer, is outside of our budget, unfortunately.

It would be nice if you had the same functionality in the PDF setup to set the bookmark level, like you can with Paragraph styles (or have some sort of hierarchy setup of the bookmarks for PDF).

[4everJang]

If you would complete the use of Structured FrameMaker by saving all content to XML, your authors would very quickly stop using the Paragraph Designer (and others) to make changes to formats, as they are lost as soon as the file is re-opened from the XML source.

With that, you can - and should - keep mapping elements to paragraph formats and base the bookmark levels on the formats. Saving to XML also opens a host of opportunities for automated reuse via XSLT. 

[QuintinSeegers]

Have to get our writers used to using Structured FM, working with Elements instead of Paragraph/Character Styles first.

Having spent 6 months investing in converting to Structured FM, going the full XML path is another project several months down the track. It would require extensive work as we'll need to write the translation to XML ourselves. (I have made attempts to convert our EDD to DDT, but ran into several errors with no indication of what the actual problem is or how to resolve it.)

One of the reasons we moved away from using Paragrah Styles was that maintaining/updating them was cumbersome and time consuming. The way we designed our FormatChangeLists is that we have a single base format that specifies the standard formatting (alignment, spacing, font, colour, size, etc.). This is used for all Elements. Each Element (where required) has an additional FormatChangeLists to change only those properties needed, e.g. font size, colour, spacing. This way, if we ever need to change font, we only need to change our base FormatChangeList, instead of the 150+ Paragraphs we historically had.

Moving away from using Paragraph Styles to Elements with FormatChangeList then back to using Paragraph Styles seems a step backwards to me because it opens it up again for our writers to change the Paragraph Styles to suit them, rather than enforcing our corporate styles via ChangeFormatLists against the Elements.

[JonBe]

Hi Quintin,

I will come back with a more considered response later today (early morning here in Oz). With my two customers, one kept paragraph styles, mainly because the contractor performing the conversion liked using them, while the other customer, dumped styles and used format change lists, which I like. There are pros and cons for both approachs. I certainly would think that the benefit of adding styles back in does not outweigh the cost of doing so.

It seesm like you do not have a DTD for your structured application? This is required to save structured content as XML along with XSLT processing if you are using a book, to assemble the component XML files into one. You can save a EDD as a DTD. I have had no reason to try this, so I have no idea how well it works. My bookmark post processing requires XML to match the //no to the //heading.

You might like to consider creating a feature request at New Feature | Tracker (adobe.com) to allow bookmarks to be generated from multiple elements in the PDF settings dialog. I would vote for that.8)

Jon

[4everJang]

I do understand your frustration about my suggestion of saving to XML and the extra work that would involve. For my customers I have always started with the XML, then mapped it to the required styles in the EDD, then started the conversion (automated or manual) from unstructured to structured FrameMaker, then got the authors to work with the structured interface. It saves a lot of hassle with the format change lists. Still, to move to XML saved documents it is not required to get rid of the format change lists and move back to paragraph styles. The EDD can remain as it is. The only extras you need are a DTD and a resd-write rules text file. For the authors, nothing changes except the files use the .xml extension rather than .fm

[QuintinSeegers]

Coming from an Unstructured FrameMaker background, moving to Structured FrameMaker was a steep learning experience for me. (These forums are litered with my questions about the topic!) My approach was moving from Unstructured to Structured, when my approach (in hindsight) should have been as you suggested: starting with XML, then EDD, then the conversion to unstructured.

More research, trial and error, down the track when we move to XML.