Publishing Responsive HTML5 from FrameMaker - duplicate IDs possible?

[BertaEmil]

Dear Community,

Unfortunately, I'm not sure whether my question is better placed here or in the FrameMaker forum. We create technical manuals with FrameMaker 2022 (17.0.6). These manuals are published directly from FrameMaker (in addition to the PDF format) as responsive HTML5 and then used as online help for a software application.

Since some descriptions are repeated in a manual, we use text insets in which we define markers (e.g., "DP123" as a marker of type "TopicAlias"). The text inset is reused in different chapters, so the same marker naturally appears in different FrameMaker files.

This was intentional and no problem when publishing with FrameMaker version 2019, as we could access the HTML pages from our software, for example, as follows:

• file:///D:/Docs/en-US/Manual/index.html#t=XYZ/A/A.htm#HT_DP123

So the name of the HTML file was passed in the call. When publishing with the current FrameMaker version 2022, this is no longer possible; page access at previously defined markers has changed completely. For a marker of the type "TopicAlias" in FrameMaker, an anchor with the pattern "CSH_" plus a sequential number is automatically created in the HTML output. The JavaScript "csh.js," which is also automatically generated when publishing as Responsive HTML5, links the marker in FrameMaker to the corresponding anchor in HTML. There you'll find, for example:

• <item mapid=\"DP123\" mapnum=\"1\" topicurl=\"XYZ/A/A.htm#CSH_2\" />

The call is now shortened accordingly and executed without specifying the underlying HTML page as follows:

• file:///D:/Docs/en-US/Manual/index.html?rhmapid=DP123

Problem: In the "csh.js" file, only the first occurrence of the jump label is taken into account, but the path to the corresponding HTML page is hard-coded there. This makes it impossible to jump from the software to the same anchor on different HTML pages. Does anyone have any ideas about this?

Thanks in advance, Andreas

[Jeff_Coatsworth]

I think I'd better move you back to the FM forum - the way RH now does this is ahead of the method that FM uses.

I don't think what you're doing is really going to work - if the same CSH tag is used in multiple topics, how is the application going to know which one to pop up for you? You either want a 1:1 relationship between the application screen and the corresponding topic OR a many:1 relationship where the application can call the 1 topic from many locations in the application.

[BertaEmil]

I see your point, Jeff. In the meantime I think we'll try another way where we don't use the marker type "TopicAlias" at all. Instead, we'll use any other marker type (except hypertext - such as "Subject") for the targets we want to jump to in the help files. These markers are translated automatically during publishing as anchors with "id" and "name" attributes (of course it would be nicer if we could use our own marker type (like "Target" or whatever) - but these special markers are missing in the HTML files completely). With these anchors the call of the topics could be like it was in FrameMaker 2019, e.g. "file:///E:/Temp/FM22/Docs/index.html#t=FM22/2.4/2.4.htm#DP319".

Thanks again for your help, Andreas

[Jeff_Coatsworth · Accepted solution]

That's one of the advantages of going the FM to RH route for online outputs - in FM I have a custom Marker Type called "CSHMarker" and in the import settings in RH I tell it to treat all "CSHMarker" types as the one I want to use for my context sensistive help calls. The other advantage is that there's more control over how paragraph & character tags are converted and newer output types, like Frameless HTML5, in RH.