Why are my <draft-comments> hidden in PDF using FM2020 but shown in PDF using FM2022?

[Ian16B7]

I have inherited a FM project that uses DITA 1.3 and FM2020. It has been working with FM2020 for a few years, and I am now trying to upgrade to FM2022. The first problem I have encountered is that in FM2020 all <draft-comments> were hidden in the published PDF, whereas they are now included/shown in a PDF published using FM2022. I am trying to solve this problem and realized that I have no idea how/why the <draft-comments> are hidden in a PDF published using FM2020. The only clue I have is the following comment from the previous FM-admin:

“The Audience attribute is also contained in the DITA file, and is nominally used to hide draft-comments.”

Details:

• I am publishing my PDFs using a .STS file (i.e. as-shipped with FM)
• I have a customized structapps.fm which points to \templates folder which contains our custom templates
• For testing, I have created from scratch a very simple .DITAMAP with 3 .DITA files: one concept, one reference and one task.
  • Each of these .DITA files has various <draft-comment> elements inside other elements (as allowed by DITA)
• I have viewed the XML of my .DITA files and confirmed that there are no conditional tags (see sample XML below)
• When I look at my .DITA files using Structured View, I can see that the Audience attribute for <draft-comments> is set to "internal" by default
  
  • This is true for both FM2020 and FM2022

Things I have tried:

• I uninstalled FM2020 and FM2022 and started "fresh" with both versions
  
  • There was no change to the behaviour of either version.
• I have tried publishing my PDFs using both the as-shipped .STS file and with our own customized .STS file
  • <draft-comments> are hidden in PDF published using FM2020 (both STS)
  • <draft-comments> are visible in PDF published using FM2022 (both STS)
• Repeating this experiment on another computer
  • I get the same results on both computers
• I opened and re-saved both my structapps.fm file and my templates to FM2022.
  • I get the same output/results with the updated files
• Using the as-shipped structapps.fm and templates
  • For both FM2020 and FM2022, if using the as-shipped files, the <draft-comments> will be published in the PDF (i.e. they are not hidden)
• I have opened the Manage Attribute Expressions dialog (using View > Filter by Attribute) in the following files using FM2020, and it always appear blank (i.e. there does not appear to be any expressions for filtering by Attribute):
  
  • My output template (i.e. used by my custom .STS file)
  • My concept.template.fm
  • Several of my .DITA files (i.e. the simple ones I created from scratch)

How might the Audience attribute be used to hide the <draft-comments> in a published PDF? Where else should I be looking? Why would this not work when I upgrade from FM2020 to FM2022?

Sample contents of one of my .DITA files:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA 1.3 Concept//EN" "technicalContent/dtd/concept.dtd" [

]>

<concept id="id249A9000PE8">

               <title>

                              <draft-comment>Draft-comment

                                             inside &lt;title></draft-comment>Sample Concept Topic

               </title>

               <conbody>

                              <draft-comment>Draft-comment inside &lt;conbody>, but NOT

                                             inside &lt;p> element.</draft-comment>

                              <p>Paragraph #1 (WITHOUT a draft-comment).</p>

                              <p>

                                             <draft-comment>Draft-comment inside &lt;p></draft-comment>Paragraph

                                             #2 (WITH a draft comment INSIDE the &lt;p> element).

                              </p>

                              <p>Paragraph #3 (WITHOUT a draft-comment).</p>

               </conbody>

</concept>

[frameexpert]

Check your output templates and make sure that your DITA-Comment and DITA-Prolog condition formats are hidden.

[Ian16B7]

@frameexpert- thanks for the suggestion. The DITA-Comment and DITA-Prolog condition formats are both hidden, for both FM2020 and FM2022 (i.e. my dialog looks the same as what you showed )

Q1: I am curious - why did you suggest this? How would these conditional tags be linked to <draft comments>?

Also, I have discovered something else which I suspect is relevant. I noticed that for my <draft comments> the @audience attribute is set = internal by default (i.e. in Structure View, if I expand to see all attributes, @audience is shown as = internal). This is true for both FM2020 and FM2022. However, if I manually edit its value, I can see that it is nominally "blank". I can see that this behaviour (i.e. default value = internal) comes from the EDD files that were originally imported into the concept.template.fm that I am using. 

So I ran the following tests ... I manually set @audience attribute for a <p> element = internal, and also manually forced the @audience attribute for a <draft comment> = internal. The following results were observed, and are identical for both the default .STS file and my custom .STS file:

FM2020:

• <draft comment> @audience = default.   Hidden in PDF
• <p>, @audience = default>.   Hidden in PDF

• <draft comment> @audience = internal.   Hidden in PDF

i.e. for FM2020, any time that the @audience attribute == internal, then the element is hidden in the published PDF.

FM2022:

• <draft comment> @audience = default.   Shows in PDF
• <p>, @audience = default>.   Hidden in PDF

• <draft comment> @audience = internal.   Hidden in PDF

i.e. for FM2022, any time that the @audience attribute is manually forced == internal, then the element is hidden in the published PDF (i.e. same as FM2020). But if it is only == internal because that is its "default" value (i.e. from an EDD), then the element is visible in the generated PDF.

Q2: why does setting the @audience attribute for an element = internal, cause it to be hidden in the generated PDF in FM2020? Where/how is that controlled? Is this just some sort of "build-in" behaviour with Framemaker?

Q3: why are FM2020 and FM2022 behaving differently for <draft comments> when I leave the @audience attribute = default value? For both versions, the default value "looks" like it is set to internal (i.e. as per the screenshot from above).

[frameexpert]

Well, if you do a content search for both draft-comment and DITA-comment in all files in the FrameMaker program folder (and subfolders), both terms show up in the ditafm.dll. So there is some internal connection between them in the DITA environment.

As far as differences between 2020 and 2022, based on other posts in the forum, 2022 updates hit the streets with some bugs in them.

[Ian16B7]

@frameexpert- again, thanks. But why do I have to be the one to find the bug in FM2022!  🙂

I will reach out to Adobe and see if they can reproduce/explain what is going on...

[Ian16B7]

@frameexpert  Feeling stupid and frustrated. Finally discovered how/why this was working for me in FM2020. The .DITAVAL files that I use were all apparently set up to filter out elements with @audience == "internal". What is frustrating is that uninstalling FM, selecting "remove all preferences" does NOT remove the reference/pointer to the last .DITAVAL that was used. I had naively assumed that FM was in the equivalent of a "fresh-state" after uninstalling and re-installing it and did not realize it was still using our .DITAVAL for filtering. Sigh.

Having said that, I think that there is a bug in FM2022 (I will report to Adobe). I have now controlled more carefully what is happening, using only the default (as-shipped) templates and can replicate the bug. More specifically, using a .DITAVAL file to filter content and "exclude" something only appears to work in FM2022 if that attribute is "manually" forced to the value that is supposed to exclude. If you rely on the "default" value of that attribute, that will not work in FM2022 (whereas it does for FM2020). The particular attribute I used was the translate attribute, because on my system (after an uninstall/re-install) I can see in Structure View that it has a default value of "no" for the <draft-comment> inside a concept topic (i.e. based on the as-shipped concept template).