Dan Korn

I don't personally know a lot about the internals of the VIPP output module. I would recommend you try two things: Download the newest version of FusionPro and see if you can reproduce the problem there. If so; Contact Support and send them your job for analysis.

The problem here is not related to the OnNewOutputFile Callback Rule. The same crash occurs even without that particular rule. This is actually a manifestation of a bug which causes a crash (in FP Server but not in Desktop ) when using the FusionProResource.pagenumber property in a rule (any rule, not just a callback) in conjunction with chunking (Output to multiple files). I apologize for the trouble. We are working on a solution to this problem. You may reference case FP-11043 in any follow-ups.

Here's a function I wrote to basically do what CopyfitLine does, using the <magnify> tag and a more efficient algorithm: function CopyfitLineWithMagnifyTag(line, widthInPoints, AllowToExpand) { var tm = new FusionProTextMeasure; tm.CalculateTextExtent(line); if (tm.messages) ReportError("CopyfitMagnifyLine: " + tm.messages); if (tm.textWidth < widthInPoints*100 && !AllowToExpand) return line; var factor = Round(widthInPoints / tm.textWidth * 10000, 0) - 1; return "<magnify type=setwidth factor=" + factor + ">" + line + "</magnify>"; } The idea here is that we don't need to iterate until we find a size that fits; we can simply take the ratio of how big the line is already compared to the desired width and use that as the magnification factor. Note that you have to specify all the font and size information with tags. So a call would look something like this: return CopyfitLineWithMagnifyTag('<f name="Arial">' + '<z newsize=12>' + Field("Address"), 360); The caller can add the optional third parameter of "true" to allow the text to get bigger, like so: return CopyfitLineWithMagnifyTag('<f name="Arial">' + '<z newsize=12>' + Field("Address"), 360, true); This function could also be modified to take parameters specifying the font name and bold/italic faces.

This is a corrected version of the post above, in which all of the entities got converted to their actual character values by the "helpful" vBulletin forum software. (This is ironic, considering that the whole point of the post is to explain how to use the entities themselves in JavaScript.) Please use [noparse] and [/noparse] tag pairs when including code samples to avoid this problem. You may also need to use [noparse][noparse] and [/noparse][/noparse] tag pairs to ensure that markup is shown literally in the forum. (Note that for the numeric entities such as &#188; the only way I could get vBulletin to show the entity literally instead of parsing it and showing the ¼ character was to "fake it out" by modifying the size or colors of some, not all, of the characters in the entity itself.) Don't be afraid to use the "Preview Post" button or edit your post to make sure the code looks right. Thanks! CORRECTED POST FOLLOWS Since almost all glyphs used in Western languages are included in both the Latin-1 encoding character set used on Windows, and in MacRoman on Mac, so FusionPro has no problem with them. However, in the great Tower of Babel that is character encoding, a few characters that are standard in Latin-1 (aka ISO-8859-1) fell through the cracks and did not get included in MacRoman encoding, including the fractional characters in question. The full list of such characters can be found here: http://www.alanwood.net/demos/charsetdiffs.html#d and here: http://home.earthlink.net/~bobbau/platforms/specialchars/#non-mac And there's some historical background here: http://ppewww.ph.gla.ac.uk/~flavell/iso8859/iso8859-mac.html and here: http://meta.wikimedia.org/wiki/Help_talk:Special_characters FusionPro does not include the fractional entities ("¼", "½", and "¾") in its entity.mac.def file, and you can't use numeric entities (such as "&#188;") either, because those characters are simply not mapped to any 8-bit ASCII values in Mac Roman encoding. The named entities will still work on Windows, however, and since you're doing the actual composition there, the real issue is how to represent and specify these characters on Mac. My recommendation is to use JavaScript to create rules that return entities designating the actual glyphs on Windows and substitute representations on Mac. You still won't be able to type them directly into the Text Editor, but you'll get the actual character symbol in your composed output on Windows, and an approximate representation on Mac. For instance, you could create a rule called "Fraction 1/4" like so: if (FusionPro.isMac) return "<superscript>1</superscript>/<subscript>4</subscript>"; //else return "¼"; (Make sure to check the "Treat returned strings as tagged text" checkbox in the Rule Editor.) The exact representation obviously depends on your superscript and subscript settings in the Paragraph Globals dialog on Mac. And superscript may affect your auto-leading. If you don't want to worry about this, you can simply return the string "1/4" on Mac. If you can find a symbol font that shows the character in MacRoman encoding, you can also do a simple font substitution with a numeric entity. I haven't found such a font, but if you do, you could do something like this instead: if (FusionPro.isMac) return "<font name=\"My Special Font\">&[size=3]#[/size]188;</font>"; //else return "¼"; The other caveat here is that this might not work with some older Mac fonts which do not contain the correct mappings under Latin-1, if they are brought over to Windows with Assets.dat. However, most modern fonts should have no problem. Even in the worst-case scenario, if the font does not contain the character, you can just switch the font on Windows, like so: if (FusionPro.isMac) return "<superscript>1</superscript>/<subscript>4</subscript>"; //else return "<font name=\"Arial\">¼</font>"; If necessary, you could use a numeric entity on Windows as well. But I doubt you will have to do that. Here's a generalized solution: function FractionCharacter(fraction) { switch (fraction) { case 1/4: case "1/4": case "14": case "¼": { if (FusionPro.isMac) return "<superscript>1</superscript>/<subscript>4</subscript>"; //else return "¼"; } case 1/2: case "1/2": case "12": case "½": { if (FusionPro.isMac) return "<superscript>1</superscript>/<subscript>2</subscript>"; //else return "½"; } case 3/4: case "3/4": case "34": case "¾": { if (FusionPro.isMac) return "<superscript>3</superscript>/<subscript>4</subscript>"; //else return "¾"; } } ReportError("No glyph for fraction " + fraction); return ""; } Using this function, you can create rules with names like "Fraction 1/4", and insert the corresponding variables in the Text Editor on either platform. If another solution becomes available in the future, or you want to try something different, you will only have to modify that single function.