A workaround is to put in a nonbreaking space but that might affect line breaks in an unwanted way.
Copy link to clipboard
This discussion should be moved to the Structured FrameMaker forum.
I believe there is a bug in the handling of the RemoveExtraWhiteSpacesOnXMLImport setting in maker.ini. This setting is intended to condense sequences of spaces used in pretty-printed XML documents to a single space. It seems to remove a space after a cross-reference as well. If you have control of the XML you are reading and can avoid such white space (or other situations in which the input may have extra spaces), the best solution is to set this flag to Off.
What version of FM are you using? I don't remember whether this bug was fixed in FM 2015.
Thank you! This solved my problem! At least in Fm2015. I hope it will work in Fm11 as well.
I am actually using both Fm11 and Fm2015.
(I have marked the issue Correct in the Adobe Forum.)
Best regards, Anna Lena
This is a great answer Lynne -- thanks. But if you use FrameMaker then you don't have control over whitespace in the XML. This is kind of a catch 22 if I understand it correctly. On the one hand, my xrefs have funky line breaks and spaces in them because there's horrible line breaking and whitespace in the XML that I get from Maker. On the other hand, my xrefs eat the space after them.
I've had to always put an xref at the end of a sentence, and also implement a script that modifies my xrefs. This is an area that could use some work IMO. Imagine how it is to bring an employee on board when you have such goofy workarounds.
Well, let's hope I'm just ignorant and there's more an average user can do to get this under control.
You raise several points: the RemoveExtraWhiteSpacesOnXMLImport bug involving xrefs, control of white space in XML, and modifying XML generated by FM with a script. Although these issues intertwine, I will try to separate my thoughts on each.
1. The bug in which FM discards white space after an xref when it is opening an XML document is serious. I have already reported it. If you, Anna, and anyone else who have run into it report it, I assume Adobe will give fixing it a higher priority.
As I mentioned in my earlier message, the bug is in FM's handling of the RemoveExtraWhiteSpacesOnXMLImport setting. If you don't have extra white space, just turn of this setting and avoid the problem. If you do have extra white space, you could use an XSLT preprocess to discard it. Anna mentioned using a non-breaking space instead of a regular space after xrefs. That workaround can negatively affect line breaking. Your technique of restricting xrefs to contexts where they are not followed by white space (such as the end of a sentence) is just not acceptable. When I first encountered the situation, I used an XML internal entity defined to be a space (which comes in as an FM variable). Solved the problem, but made it harder for less sophisticated users to make some edits within FM. I just read my bug report. I claimed that using a character reference (in particular, ) instead of a space bypassed the bug. That's another change that could easily be made with an XSLT preprocess.
2. I am not sure what you mean about funky line breaks and spaces in your xrefs. Are you talking about the way the XML is formatted? Xrefs are empty elements in XML; the only white space within them should be between attributes. Why is this a problem? Or are you referring to a workaround to the bug?
3. Automatic processing of white space is extremely difficult. I don't believe generating or interpreting XML white space optimally is possible without knowledge of the purpose of individual elements. Typically, white space isn't important to extract significant content from an XML document. Sometimes (when dealing with "pre-formatted" text), though, it is crucial. Furthermore, white space is something that is not there. As readers, we don't pay attention to it--if something we see isn't formatted the way we'd like, we complain about the way the visible characters are formatted, not about the use of white space. The computer notion of white space "characters" is bizarre--characters are things we see on a blank page, not the space between them. FM's conventions aren't that bad; starting a new line in XML output for paragraph elements, keeping inline elements on existing lines.
4.You mention a script that modifies your xrefs. I don't know if you used "script" as a generic term or specifically meant ExendScript. I am surprised to read on this forum and various other discussion lists about the number of people who use ExtendScript (or FrameScript or the FDK) to modify XML generated by FM. It is certainly a viable approach and for some type of processing (such as retrieving page or line numbers, or the text FM generates for xrefs) is necessary. In other cases, though, changes can be made with XSLT. There are many reasons to choose either an FM-knowledgeable tool (ExtendScript, FrameScript, the FDK) or XSLT, not least of which is the expertise of the person doing the work. Since XSLT was specifically designed to manipulate elements while the FM tools focus on documents that may happen to contain elements, though, many transformations require significantly less effort in XSLT.
The issue is now reported as a bug #4122161.
/Anna Lena Soderling
This issue has not been fixed and it occurs not only after xrefs but after other inline elements. For example, we have a simple <command> element that just bolds text. We have experienced multiple (but apparently random) instances in which the space disappears after this element.
How can I escalate a bug? I did search for this bug at Tracker and couldn't locate it.