Is it a bug? Doesn't work like a feature.

[cbdebris]

One of the team discovered that when he conditionalizes a crossref in the format (see page 1) at the end of a sentence and adds a space before the open parenthesis (inside the condition tag but just before the crossref tag), saves and closes the file, the space may or may not be there when he opens the file again -- and the space won't be there when he generates a PDF.

For example:

Code: Select all

<MadCap:conditionalText MadCap:conditions="hide"> <MadCap:xref href="Entity_Status.htm#top" target="" title="" alt="" class="seepagelower">(see page 1)</MadCap:xref></MadCap:conditionalText>.

Because you never know whether the space will be there when you open the file again, I suggested using a nonbreaking space instead of a regular space. This fix works for the PDF. But it's a crazy, tedious fix.

Could we add the nonbreaking space before the crossref? Surely. But that doesn't explain why a normal space displays in the code (and sporadically in the browser) but fails to display in the PDF.

[NorthEast]

I did a quick test; if I highlight the a space followed by an xref, and then apply a condition, Flare converts the space to a fixed space in a <![CDATA[ ]]> tag.

Code: Select all

This is a link to<MadCap:conditionalText MadCap:conditions="Test"> <![CDATA[ ]]><MadCap:xref href="Topic.htm" target="" title="" alt="">Topic title</MadCap:xref></MadCap:conditionalText>.

If you use your method of applying the condition to the xref, and then inserting the space; the space will not be a fixed space.

When HTML is displayed in a browser, it will usually ignore any 'surplus' spaces; e.g. spaces that are between tags and not inside tags, or multiple spaces.
It is fairly common in HTML to have to use fixed spaces (such as   or <![CDATA[ ]]>) when you need a space in such situations.

[cbdebris]

Thank you Dave. Just wanted to make sure that I hadn't overlooked something.

[techwriter31]

Yeah, I reported a similar issue to tech support last year. When I inserted two variables side-by-side and then attempted to insert a manual space between the variables, Flare automatically inserted the CDATA tag between them and no space was visible in the PDF generated output. The workaround I used at the time was to replace the "<![CDATA[ ]]>" tags with "&160;". I didn't think this was a viable solution because it's tedious and error-prone with several writers working on the projects.

Tech support did some testing and said they believe it's a bug for PDF outputs specifically. They recommended that we do a global find/replace prior to the final build, allowing the other writers to follow their normal workflow of inserting the spaces between variables. I ended up abandoning variables for the time-being due to this issue, and the fact that it makes translations more difficult.

[LTinker68]

They recommended that we do a global find/replace prior to the final build, allowing the other writers to follow their normal workflow of inserting the spaces between variables.

If you do that, I would replace the <![CDATA[ ]]> with a blank space. The reason being that the   tag is actually a non-breaking space, which would prevent it from wrapping the content to the next line when it should.