Yes, the "Treat returned strings as tagged text" box makes a significant difference in the way that the resulting text is handled by FusionPro, and this includes the way that spaces are handled.
For a lot of the rules you write, it probably doesn't matter whether you check the "Treat returned strings as tagged text" or not. But this is a very important setting, and it can make a big difference in certain rules. The thing to remember is that, if you're sending tagged markup to FusionPro (such as in a rule with the "Treat returned strings as tagged text" box checked), then all the text goes through the tagged markup parser, which collapses all white space, and transforms consecutive spaces, tabs, and new lines into single spaces. This is exactly the way that HTML and XML work. Imagine some text like this, with line breaks and indents, in an HTML file: This is some HTML on my web page, and this is part of the same line, and I don't actually get a new line in the browser window unless the text wraps in the frame or I put in a <p> or <br> tag. The tagged markup parser in FusionPro will set this text pretty much the same way as a web browser would render the HTML. The output will look something like this (and will be wrapped in this email): <output> This is some HTML on my web page, and this is part of the same line, and I don't actually get a new line in the browser window unless the text wraps in the frame or I put in a or tag. </output> Notice how the literal line breaks and the extra spaces and/or tabs at the beginning of the lines in our text are gone, and the <p> and <br> tags are replaced with line breaks in the output. The reason why the parser collapses white space like this goes back to the early days of HTML, where, when you send plain text around, especially with older transmission protocols (such as email forums like this one), lines get wrapped and indented and you don't want the output text to have those extra spaces and new lines in it. So, if you want to increase the amount of space between words, you have to either uncheck the "Treat returned strings as tagged text" box, use entities (more on those below), or use something else like tab stops to achieve the desired horizontal space. Now, if I put some text like this in a rule: return "A B"; And check the "Treat returned strings as tagged text" box, I get a bit of extra space between the letters "A" and "B" in the output. If I put in more " " entities, the space increases. You can also try something like this: return "A B"; Now, imagine you still have the "Treat returned strings as tagged text" box checked, and you return something like this: return "Hi there!"; Then you change the rule like so: return "Hi there!"; Or even: return "Hi\t\t\t\n\n\nthere!"; When you click Validate, the results of these three rules are going to look different, and the actual return value from each of these rules is indeed different. But as I explained above, that returned text is still going to be processed by the tagged markup parser in FusionPro, and it's going to throw away all of that extra white space, so the composed output of all these rules is going to be identical. If you UNCHECK the "Treat returned strings as tagged text" box, then it's a different story. In that case, the extra spaces are converted to " " entities behind the scenes, and any spaces, tabs, and new line characters you return from your rule are going to be processed literally, making the output from each of the above rules very different. Also, it doesn't matter at all whether you do this: return "A B"; or return "A" + " " + " " + " " + " " + " " + "B"; The value returned from the JavaScript rule is exactly the same, so both rules are going to give you exactly the same result. There are a few other things to keep in mind about how spaces are processed in FusionPro, both in the JavaScript editor and in the tagged markup parser. The first is that, when a space is typeset, it's not actually like setting a letter. Obviously, spaces are word boundaries, and lines can break where spaces occur (and obviously words themselves can be broken if hyphenation is enabled, but that's another show). If you open up, say, an output PDF generated by FusionPro in a plain-text editor, you will see the text of the words, but there are no space "characters" in the PDF, just commands telling the PDF engine where to place each word. Inter-word spacing can also be adjusted based on your paragraph alignment, with full justification. This adjustment can be controlled by the Word Spacing settings in the Global Paragraph Settings dialog. Also, the widths of spaces are not like the widths of other characters: if you put in several spaces in a row, they may not take up as much space as the width of another letter. Furthermore, there is more than one kind of "space" character, and different characters are handled differently. Specifically, there are five different kinds of spaces which FusionPro will handle. The first is the regular old space character, ASCII 32, or " " in JavaScript. The others are listed in your entity.def (or entity.mac.def) file, like so:   18 // thin space 1/6 of em space   19 // en space 1/2 of em space   20 // em space 160 (202 on Mac) // non-breakable space The " ", " ", and " " entities specify a specific amount of horizontal space. The " " entity specifies that a line can't break at that position, but otherwise it takes up the same amount of space as a regular space character. Dan +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Calling all FP Web Users! Do you have a question or lots of knowledge to share about FusionPro Web? If so, join our Printable Web to Print Users' Forum today! Send email to [EMAIL PROTECTED] to find out how! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -- Users of FusionPro Desktop have unlimited free email support. Contact Printable Support at [EMAIL PROTECTED] -- View FusionPro Knowledge Base, FusionPro Samples at www.printable.com/vdp/desktop.htm -- You are currently subscribed to fusionpro as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] -- -- Note: All e-mail sent to or from this address will be received or otherwise recorded by the e-mail recipients of this forum. It is subject to archival, monitoring or review by, and/or disclosure to someone other than the recipient. Our privacy policy is posted on www.printplanet.com --
