Exception to the AllCaps Rule for "&"

Could someone help with adding an exception to the canned "AllCaps" rule that basically ignores the "Ampersand" character.

The rule generally works great in PrintFusion, but when template is uploaded to Printable, the "&" disappears.

Thanks much.

var Var1 = "MemberCompany";

var CaseSelection = "allcaps";

if(CaseSelection == "allcaps")

return ToUpper(Field(Var1));

if(CaseSelection == "smallcaps")

return "<smallcap>" + Field(Var1) + "</smallcap>";

if(CaseSelection == "propercase")

return ToTitleCase(Field(Var1));

if(CaseSelection == "lowercase")

return ToLower(Field(Var1));

Change the line after if(CaseSelection == "allcaps") to this:

return "<uppercase>" + TaggedDataField(Var1) + "</uppercase>";

It would be a nightmare going through all of the Iforms and making the change to &amp.

The second solution works great, using:

return "<uppercase>" + TaggedDataField(Var1) + "</uppercase>";Thanks guys.

Interestingly, I just ran into this problem this morning using FP's ToUpper() method. If I create a test rule:

var sample = "B&R Body Shop";
return ToUpper(sample);

validating correctly returns "B&R BODY SHOP", but placing that rule in a text frame and previewing returns "B BODY SHOP".

If I replace the ampersand with its corresponding entity (& amp ; -- minus spaces) the result in a preview is "BR BODY SHOP". Adding tags instead of using a method (for a value not from a field) also drops the ampersand.

Is this an issue with JavaScript, FusionPro or both? Or, since this validates correctly, but previews wrong, will this be fixed in the next version of FP?

Interestingly, I just ran into this problem this morning using FP's ToUpper() method. If I create a test rule:

var sample = "B&R Body Shop";
return ToUpper(sample);

validating correctly returns "B&R BODY SHOP", but placing that rule in a text frame and previewing returns "B BODY SHOP".

 

If I replace the ampersand with its corresponding entity (& amp ; -- minus spaces) the result in a preview is "BR BODY SHOP". Adding tags instead of using a method (for a value not from a field) also drops the ampersand.

Two questions:

1. Do you have "Treat returned strings as tagged text" checked in the rule?
   
2. Are you using tagged markup input? Or, for flat file, do you have "Treat field values as tagged text" checked on the "Data Fields - Flat File" step of the Define Data Source Wizard?
   

Both of these can affect exactly what that rule does.

Is this an issue with JavaScript, FusionPro or both? Or, since this validates correctly, but previews wrong, will this be fixed in the next version of FP?

I'm not sure you can say for sure that it "validates correctly, but previews wrong." Obviously what you see when you preview doesn't always exactly match the composed output, especially with tagged markup. So I'm not sure there's anything to fix in FusionPro. It's probably a job-specific issue, but I'd have to see the job to know for sure.

Two questions:

 

1. Do you have "Treat returned strings as tagged text" checked in the rule?
   
2. Are you using tagged markup input? Or, for flat file, do you have "Treat field values as tagged text" checked on the "Data Fields - Flat File" step of the Define Data Source Wizard?
   

Both of these can affect exactly what that rule does.

1) The ampersand disappears when checking the "treat as tagged" box. Changing the value of sample to "B&-amp-;R" (minus the dashes) returns "BR BODY SHOP". (If I uncheck the "tagged" box, value is returned correctly either way.)

2) The template in question is using XML for its data although the test code above obviously is not using a field from that data.

I'm not sure you can say for sure that it "validates correctly, but previews wrong." Obviously what you see when you preview doesn't always exactly match the composed output, especially with tagged markup. So I'm not sure there's anything to fix in FusionPro. It's probably a job-specific issue, but I'd have to see the job to know for sure.

By questioning the "validate correct/preview wrong" issue, I am referring to the separate javascript libraries mentioned in previous threads where validation result was different than preview/composition.

My job has a rule which pulls in a value from the XML data and converts the string to uppercase which (unintentionally) removes the ampersand whether it appears in the data as a character or an entity. If I remove the ToUpper() method, the ampersand shows correctly in the output. I have not found a viable workaround, but fortunately the customer decided they did not want the final composition to appear in all caps so I've dodged the issue for now.

1) The ampersand disappears when checking the "treat as tagged" box. Changing the value of sample to "B&-amp-;R" (minus the dashes) returns "BR BODY SHOP". (If I uncheck the "tagged" box, value is returned correctly either way.)

2) The template in question is using XML for its data although the test code above obviously is not using a field from that data.

This is the expected behavior if you return a string containing an ampersand from a rule with "Treat returned strings as tagged text" checked. The tagged markup parser always sees the ampersand as the beginning of an entity. This has always been the case in FusionPro. Read this for more explanation:

http://www.mail-archive.com/fusionpro@lists.printable.com/msg02721.html

If you're returning any raw data field values from a rule with that box checked, then you need to call TaggedTextFromRaw (formerly NormalizeEntities in older versions of FusionPro) on the data so that it gets converted properly to tags which can be parsed. If you don't do this, the tagged markup parser sees "&R" as an entity, which it can't resolve, and you will definitely have a warning message about this in the .msg file when you do a full composition. And I always recommend doing a full composition and looking in the .msg file when the Preview doesn't look the way you expect.

Note that this has absolutely nothing at all to do with the ToUpper function. You could simply return the string and see the same problem:

// WRONG if "Treat returned strings as tagged text" is checked
return "B&R Body Shop";

What you want to do is this:

return TaggedTextFromRaw("B&R Body Shop");

Note the difference in the return value when you validate this: "B[noparse]&[/noparse]R Body Shop". THIS is the correct result that you want to see in validation if you have the "Treat returned strings as tagged text" box checked in order to get the correct output.

Now, the one caveat to my statement that it has nothing to do with the ToUpper function is that, if you are using a function such as ToUpper in conjunction with TaggedTextFromRaw, then the order in which you call the functions matter, because entities are case-sensitive. So you need to do it like this:

return TaggedTextFromRaw(ToUpper("B&R Body Shop"));

If you do it the other way then the entity will be malformed as [noparse]&AMP;[/noparse] and the output will be wrong:

// WRONG - this mangles the case-sensitive [noparse]&[/noparse] entity
return ToUpper(TaggedTextFromRaw("B&R Body Shop"));

The other thing is that, if you have a job which may switch between flat file and tagged markup data, such as a job that you're uploading to MacromCentral, then there's a refinement to this logic: Instead of using TaggedTextFromRaw all the time, you need to first check that the data field isn't already tagged, otherwise you'll change "[noparse]&[/noparse]" to "[noparse]&[/noparse]", which isn't right. If you're not doing anything else to the string like making it upper-case, you can use the TaggedDataField function in place of Field, which accounts for this. However, if you call ToUpper on the result of this, you'll have the same problem as above, where the entity will be malformed as "[noparse]&AMP;[/noparse]". That's why I recommend, as I did to the original poster, using the <uppercase> tag instead, like so:

return "<uppercase>" + TaggedTextFromRaw("B&R Body Shop") + "</uppercase>";

Putting this all together, the way this will work the most reliably, regardless of the format of the data file, is this:

return "<uppercase>" + TaggedDataField("YourFieldName") + "</uppercase>";

Note that this is pretty much exactly what I suggested in post number 3 in this very thread.

By questioning the "validate correct/preview wrong" issue, I am referring to the separate javascript libraries mentioned in previous threads where validation result was different than preview/composition.

I assume you're referring to this:

http://forums.printable.com/showthread.php?t=2656

The issues noted there with differences between preview and composition due to different JavaScript libraries are seen only with fairly esoteric JavaScript functionality, such as using regular expression lookahead patterns. There's no difference in how any version of the JavaScript library would interpret any versions of the rules in this thread, as the ToUpper function is just a wrapper around the standard JavaScript String.toUpperCase() function. So that different JavaScript libraries thing has nothing to do with this. The "difference" you saw in the raw validated result and the output was due to telling FusionPro to treat the result as tagged markup, as I explained above.

My job has a rule which pulls in a value from the XML data and converts the string to uppercase which (unintentionally) removes the ampersand whether it appears in the data as a character or an entity. If I remove the ToUpper() method, the ampersand shows correctly in the output. I have not found a viable workaround, but fortunately the customer decided they did not want the final composition to appear in all caps so I've dodged the issue for now.

My last code block above should work fine for you.