Chris,
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.
--Lynne
1 Correct answer
6
Replies
AdChoices