Hi Jay, sorry to hear about that.

There are very little customers that take any Output Format as-is, they all need styling or branding. This could be about fonts, color schemes, logos or things that need to align with the chosen OASIS DITA information architecture and more. 

As you mention an issue, could you perhaps also describe the issue, this way others that might have worked around it could help you out. Or describe what has changed as you currently notice this issue on the tri-pane output format which was fielded multiple releases ago. 

Furthermore, a product version number is the shortest bit of information that describes how a system is working, ranging from the good to the less good behavior :-)

Best wishes,
Dave

Hi, Dave. Thank you for commenting. I'm sure it shows that this has been a frustrating experience for us.

I did make a post here about this issue a few weeks ago, but since then we found the apparent cause, which was confirmed on your side by RWS Support (Case 00823709). I should say "apparent cause, but no apparent solution." (And, except for the bad news at the end, my experience with the RWS Support contact (Sarah S.) was outstanding.)

We are using Tridion Docs 14 SP3. We have not customized ishWebHelp at all. We use some of the output from the unmodified ishWebHelp plug-in as "building blocks" for a customer-defined deliverable package. So we're not delivering the Tri-pane package. We're not using the Tri-pane UI, CSS, search index, or JavaScript. We are only using the HTML topic content, the images, and most importantly for this discussion, the "toc.html" file.

In other words, I was never seeking support for a customized ishWebHelp use case. Only core product as delivered from RWS.

Here is a summary of the issue/bug:

• When we add an ishCondition to a topicref and publish with the ishWebHelp Tri-pane output, the title is missing from the navigation TOC, regardless of whether the condition is turned on or off in Publication Manager.
• Note that this behavior is happening ONLY for submap topicrefs. If the topicref with an ishCondition is for a topic and not for a map, then the ishCondition is processed correctly in the output.
• The only way we can get the topicref to display in the TOC for the ishWebHelp Tri-pane output is to remove the ishCondition before publishing (not practical or desirable).
• This only impacts titles in the navigation TOC. Corresponding child link titles in the content pane are not missing (which is curious to me).
• This seems to have nothing to do with how navtitles are used.
• I am told by RWS Support that CHM and PDF outputs do not have this issue/bug.

Some other thoughts to add to this:

• I am unable to determine if this issue was present in previous versions of Tridion Docs (i.e. LCA and Trisoft). We have been using this process for 10 years. It could be that our authoring teams didn't use ishConditions as aggressively (i.e. in maps) as we do today.
• I looked all the XSLT files in the ishWebHelp plug-in. I read XSL well enough to understand what's going on, but I am not an XSLT developer. Nothing jumped out to me.
• What surprised me the most is that the issue stems from ishConditions. Apparently I have had a fundamental misunderstanding all these years of what the XML dataset that is handed off to DITA-OT plug-ins looks like. I had always thought that ishConditions were all resolved and all condition filtering done before the presumed "clean" DITA XML was handed off to the DITA-OT.

-Jay Baldwin

Hi, Dave. Thank you for commenting. I'm sure it shows that this has been a frustrating experience for us.

I did make a post here about this issue a few weeks ago, but since then we found the apparent cause, which was confirmed on your side by RWS Support (Case 00823709). I should say "apparent cause, but no apparent solution." (And, except for the bad news at the end, my experience with the RWS Support contact (Sarah S.) was outstanding.)

We are using Tridion Docs 14 SP3. We have not customized ishWebHelp at all. We use some of the output from the unmodified ishWebHelp plug-in as "building blocks" for a customer-defined deliverable package. So we're not delivering the Tri-pane package. We're not using the Tri-pane UI, CSS, search index, or JavaScript. We are only using the HTML topic content, the images, and most importantly for this discussion, the "toc.html" file.

In other words, I was never seeking support for a customized ishWebHelp use case. Only core product as delivered from RWS.

Here is a summary of the issue/bug:

• When we add an ishCondition to a topicref and publish with the ishWebHelp Tri-pane output, the title is missing from the navigation TOC, regardless of whether the condition is turned on or off in Publication Manager.
• Note that this behavior is happening ONLY for submap topicrefs. If the topicref with an ishCondition is for a topic and not for a map, then the ishCondition is processed correctly in the output.
• The only way we can get the topicref to display in the TOC for the ishWebHelp Tri-pane output is to remove the ishCondition before publishing (not practical or desirable).
• This only impacts titles in the navigation TOC. Corresponding child link titles in the content pane are not missing (which is curious to me).
• This seems to have nothing to do with how navtitles are used.
• I am told by RWS Support that CHM and PDF outputs do not have this issue/bug.

Some other thoughts to add to this:

• I am unable to determine if this issue was present in previous versions of Tridion Docs (i.e. LCA and Trisoft). We have been using this process for 10 years. It could be that our authoring teams didn't use ishConditions as aggressively (i.e. in maps) as we do today.
• I looked all the XSLT files in the ishWebHelp plug-in. I read XSL well enough to understand what's going on, but I am not an XSLT developer. Nothing jumped out to me.
• What surprised me the most is that the issue stems from ishConditions. Apparently I have had a fundamental misunderstanding all these years of what the XML dataset that is handed off to DITA-OT plug-ins looks like. I had always thought that ishConditions were all resolved and all condition filtering done before the presumed "clean" DITA XML was handed off to the DITA-OT.

-Jay Baldwin