FM bug: newline characters after PI in XML output

Advocate ,
May 16, 2017

Copy link to clipboard

Copied

Hello all,

I have stumbled across a bug that has apparently been present in FM since version 7.1 and nobody ever noticed. I guess I am the only one doing this crazy stuff then. Here is the bug description:

When writing a text-only element out to XML that contains a marker (which is NOT a conditional text marker), FM introduces a newline character immediately following the PI. I found this when using a custom marker to mark the paragraphs that have a change bar in FM. I know that the @status should be used to drive the change bar but the customer does not have these attributes and was not allowed to make changes to the EDD or DTD. When reading the XML back into FM and removing the markers (using them to set the change bars in the right locations again), there were extra spaces (the newline characters in the XML). The only workaround I could find is creating an event handler script that opens the XML as text file, either after writing it out or before reading it back in, and replaces all newline characters by spaces. This might cause other problems but the XML files were pretty small, so those problems did not appear in my case.

I am posting this so that you know that, in these remote corner cases, you might get observe strange behaviour with white space appearing where it should not be. In such cases, open the XML in a text editor and check whether newlines were added after your PIs.

Ciao

4everJang

TOPICS
Structured

Views

543

Likes

Translate

Translate

Report

Report
Reply
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Adobe Community Professional ,
May 16, 2017

Copy link to clipboard

Copied

Jang,

   Using the patched FM 2017, I am unable to duplicate the situation you describe. If I did run into it, I would use XSLT rather than a script that edited the XML file as a text file, to remove the unwanted newline.

   Does your application use a custom API client or an XSLT post-process that might affect this result?

   I modified the XDocBook application that is included with FM by removing the custom API client. In a WYSIWYG document, I created four <para> elements, each of which is a separate paragraph. In two of them, I inserted <emphasis> elements, which are text range elements that use italics. I inserted a non-element markup using a custom marker type at the end of the content of the first <emphasis> and just after the second <emphasis> element. In one of the <para> elements without an <emphasis>, I inserted a marker just after all the text; for the other, I inserted a marker immediately after the element.

  I saved the document as XML, trying it both with RemoveExtraWhiteSpacesOnXMLImport set to On and with it set to Off. The maker.ini setting did not make a difference.

  In three cases, I did not get a newline after the PI. The third case was when the marker followed the <para>. In this case, the PI occurred after the </para> end-tag (on the same line) and was followed by a blank line. However, FM ignores white space between paragraph elements, so the extra newline is ignored on import.

       --Lynne

Likes

Translate

Translate

Report

Report
Reply
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
4everJang AUTHOR LATEST
Advocate ,
May 16, 2017

Copy link to clipboard

Copied

The problem only occurs if a marker (but not for conditional text) appears anywhere in an element that only allows TEXT. The <para> allows other child elements and I assume <emphasis> also allows nesting other child elements.

The RemoveExtraWhiteSpaceOnXMLImport does not seem to be about exporting the XML at all, so I would not expect any change in behaviour from that one. Also, if there is a newline between one part of the text content and the next, it SHOULD become a whitespace. So this RemoveExtraWhiteSpaceOnXMLImport should not eat that newline up at all.

The fact that the problem only occurs in text-only elements and only with non-conditional text markers makes it quite rare. But it is a bug and should be fixed. Let me know if you can reproduce it in the exact circumstances I describe above. In the situations you described there is no problem, as the element has mixed content.

Ciao

4everJang

Likes

Translate

Translate

Report

Report
Reply
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more