"&" generating instead of ampersand

[CCS_Printing]

I'm using the ToUpper() in FusionPro on variables that use the fonts Mr Eaves Mod OT-Light, and Mr Eaves Mod OT-Bold, and then the item is then moved to MarcomCentral for ordering as a versioned item. For some reason when a user enters an ampersand "&" the item prints "&" (without the quote marks). The code works fine in FusionPro.

 

It does not seem to matter if I use straight JavaScript or the built in format Rule, the value returned is alway &.

 

The Mr Eaves Mod OT fonts were not working well, and needed to be converted from OTF to TTF but still generate the &.

 

If I enable the "Treat returned strings as tagged text" then any ampersand that is entered into the field does not generate on the item (i.e. it disappears)

 

Why?

Edited October 20, 2022 by CCS_Printing

[Dan Korn]

This has nothing to do with your font. It has to do with how FusionPro handles tagged markup (XML) data vs. "flat" (raw, or untagged) data.

 

This is a frequently-asked question. If you search for "ampersand" here on this forum, you'll see a lot of similar questions, like this:

https://forums.pti.com/showthread.php?t=5309

 

My reply in that thread is the short answer. Here's a longer explanation:

 

When designing a template in FusionPro Creator, you're typically using "flat file" (delimited) data (tab-delimited, CSV, Excel, etc.), which usually has the data represented literally. An ampersand is just an ampersand, etc., such as in "PB&J".

 

But a data file generated from a web form in MarcomCentral Portal (or EFI DSF and other such systems) is an XML (tagged markup) file. (This is because you can put formatting with tags like <b> in your template data with the rich text editor in Marcom.) And as in any XML file, certain characters, like ampersands, double-quotes, and less-than and greater-than, have to be represented by XML entities (& " et al), so that they're not misinterpreted as tags.

 

So if you enter "PB&J" into the web form in Marcom, that will generate a data file with "PB&J" in it. (Actually it will be something like <story copyhole="name">PB&J</story> .)

 

These data field values from the XML data file are brought into the FusionPro job as markup, with those entities present. So in rules, which can return either tagged/formatted markup or "raw" unformatted data, you have to account for whether the original data is tagged or raw.

 

I don't know exactly what your rule looks like, but presumably it's something like this:

return ToUpper(Field("name"));

 

Let's just back up a bit and think about what happens if you return just the field, without ToUpper, like so:

return Field("name");

 

Remember that if the data entered into the web form in MarcomCentral is "PB&J", the XML data file generated from that form and used in the FusionPro composition is "PB&J". If you return this from a rule directly with the Field function, you'll see the & entity in the output.

 

This is where the "Treat returned strings as tagged text" box comes in. If you check that box, you'll get the expected "PB&J" in the output, because the entity returned from the rule will be parsed back into the literal ampersand. (Likewise, when a data field is used directly as a variable in a text frame, without a rule, FusionPro takes into account whether the data is tagged or not.)

 

However, when you take that data field value "PB&J" and call ToUpper on it, it gets converted to "PB&AMP;J", which is basically what you're seeing now in the output.

 

Checking that "Treat returned strings as tagged text" box should handle the tagged markup, but there's another problem. Unlike the "&" entity, "&AMP;" is not a valid entity, so you'll get a warning in the composition log (which is hard to find in a Marcom composition) and nothing at all for that entity in the output, so the output will be just "PBJ". (Entities in FusionPro markup are case-sensitive for historical reasons to differentiate things like ñ for lower-case ñ and Ñ for upper-case Ñ.)

 

How to get out of this dilemma?

 

Fortunately, there are several helper functions to deal with this. The most important ones are TaggedDataField and UntaggedDataField. These functions can figure out the data file format and return a string in the correct tagged or untagged format. You want to use these instead of the regular Field function to ensure that the data you're dealing with is in the right representation.

 

You'll want to change your rule to:

return ToUpper(UntaggedDataField("name"));

 

This will properly convert the tagged markup from the data to the "raw" representation with the literal ampersand, and that will be capitalized, and the output will be correct. (Assuming you don't have any actual formatting tags such as <b> and <i> from the rich text editor in Marcom in the data.)

 

Note that even in the simple case, without ToUpper, this change is required to handle both tagged and untagged data properly:

return UntaggedDataField("name");

 

You might ask, why don't we change FusionPro to make the Field function always returns either the tagged or raw/untagged data, so that rules always work the same way, regardless of the data format? Well, we have thought about that, but for one, it would break a lot of existing jobs in the field, and two, it would still be a problem because in many cases, you do really need to know whether the data is tagged or not to be able to properly examine and modify it in different kinds of rules.

 

Hope this helps.

[CCS_Printing]

That works and thank you for the expansive explanation! I worked for another web-to-print solution and I totally get the need-to-fix-but-don't-wanna-break-all-the-old-stuff concept!