OnCopyfit on Server - MarcomCentral (PTI) and FusionPro User Communities

step · #1 July 30th, 2015, 04:21 PM

Does the OnCopyfit callback work differently when composing on the server (via command line) than it does when composing locally?

My OnCopyfit rule looks like this:

Code:

if (!Copyfit(new MagnifyAttributes("text", 25, 400, 6, 72))) {
    ReportWarning("Could not copyfit text in flow " + FusionPro.Composition.CurrentFlow.name);
}

Upon examining the .msg file after a local composition, I see the warning that I printed (in red) followed by a pretty specific log of what went wrong:

Quote:

OnCopyfit, line 2: warning: Could not copyfit text in flow headline
Word <TESTTEST> does not fit in frame after line 0.
The amount of text inserted into a flow exceeds the depth
of all frames in the flow <headline>. Text is truncated.
Text does not fit in the last frame on page 2 at (0.31, 4.62).

When composing on the server, I only get the detailed version and anything that I put within that 'if' statement is ignored. That leads me to believe that the 'Copyfit' function always returns true when composing on the server. Could that be true? With that in mind, I tried this:

Code:

if (!Copyfit(new MagnifyAttributes("text", 25, 400, 6, 72))) {
    Print("doesn't fit");
}
else {
    Print("fits");
}

and got the following output when composing on the server:

Quote:

fits
Word <TESTTEST> does not fit in frame after line 0.
The amount of text inserted into a flow exceeds the depth
of all frames in the flow <headline>. Text is truncated.
Text does not fit in the last frame on page 2 at (0.31, 4.62).

Ultimately, the reason I'm asking is because I'm trying to move that information into an XML log file to parse out later but it doesn't appear that copyfitting warnings are something that the XML log reports by default. My suspicion is that the errors that get reported in the XML log are system error codes and they'd be referenced by number. But, to me, a record failing to copyfit is an error I'm concerned about so I'd like to put it in the log like so:

Code:

if (!Copyfit(new MagnifyAttributes("text", 25, 400, 6, 72))){
	var warning = "Could not copyfit text in flow " + FusionPro.Composition.CurrentFlow.name;
    ReportWarning(warning);
    FusionPro.Composition.LogXMLMetadata('copyfit',warning);
}

For what it's worth, the templates are FP8.2.7 and the servers (I've tried 2 with the same results) are versions 8.2.5 and 9.3.15. Anyway, any insight or suggestions would be much appreciated!

Dan Korn · #2 July 31st, 2015, 10:37 AM

Quote:

Originally Posted by step

Does the OnCopyfit callback work differently when composing on the server (via command line) than it does when composing locally?

No. For the same job, with the same fonts, and the same version of FusionPro, it should work the same way.

Quote:

Originally Posted by step

When composing on the server, I only get the detailed version and anything that I put within that 'if' statement is ignored. That leads me to believe that the 'Copyfit' function always returns true when composing on the server. Could that be true?

No. Well, you do seem to get consistent results from this particular job, but in general, it would a major issue affecting thousands of templates in lots of applications, such as MarcomCentral, if copyfitting was just a no-op in Server.

Quote:

Originally Posted by step

With that in mind, I tried this:

Code:

if (!Copyfit(new MagnifyAttributes("text", 25, 400, 6, 72))) {
    Print("doesn't fit");
}
else {
    Print("fits");
}

and got the following output when composing on the server:

That output looks basically the same to me. The text doesn't fit at all. Now, that said...

Quote:

Originally Posted by step

For what it's worth, the templates are FP8.2.7 and the servers (I've tried 2 with the same results) are versions 8.2.5 and 9.3.15.

There may be a subtle difference in whether the Copyfit function returns true or false right away if it can't fit anything between versions 8.2 and 9.3. Our regression testing is focused on making sure that output is identical between versions, but not so much on whether all the warning messages in the log file are the same.

Or perhaps there's something different about the way the fonts are handled. You are using the Assets.dat file for the Server composition, right?

Either way, at the end of the day, both output files should look the same, and your text simply doesn't fit, and that's really all that matters, right? But it's also true that you're going to have the best results if the versions of FusionPro on your Desktop and Server machines are at least the same major version.

Quote:

Originally Posted by step

Ultimately, the reason I'm asking is because I'm trying to move that information into an XML log file to parse out later but it doesn't appear that copyfitting warnings are something that the XML log reports by default.

Correct. Well, it's not just copyfitting warnings, it's anything that you write out with ReportWarning or Print. These messages appear in the main composition log (.msg) file, but not in the XML log. The only way to put custom information into the XML log is to call FusionPro.Composition.LogXMLMetadata.

Now, the ReportError function is a bit different. That still only writes to the main log file, but it does set a Medium error severity level for the record. We'll come back to that in a bit...

Quote:

Originally Posted by step

My suspicion is that the errors that get reported in the XML log are system error codes and they'd be referenced by number.

No, the "status" attribute in the <summary> tags the end of the XML log is the FusionPro error code for the composition, which also gets returned from the FusionPro.exe process. These codes are listed in the "Message Codes in FusionPro" section of the "ServerFPDGuide.pdf" reference.

The "status" attribute of the <record> tag that gets reported for each record is actually an error severity level, which corresponds to the values in the "Abort on errors of this type" drop-down list on the Advanced tab of the Composition Settings dialog (where 1=Severe, 3=Medium, 5=Minor).

Speaking of which, that brings us to what it seems you're really trying to accomplish, which is to treat a record with a fitting failure as an error record:

Quote:

Originally Posted by step

But, to me, a record failing to copyfit is an error I'm concerned about

Sure. But it seems to me that what you're really concerned about isn't so much that a text flow failed to copyfit, but the more general condition that a text flow failed to fit, right? In other words, I think the error you're really concerned about is "The amount of text inserted into a flow exceeds the depth of all frames in the flow <headline>. Text is truncated." (That's a "Medium", or "3" error.)

And you want to fail the record in that case, right? That can be done with that "Abort on errors of this type" drop-down, and the other drop-down right below it. Set the first drop-down to "Minor" or "Medium", and the other to "Skip the record with error." Then you don't really need to log any specific message to the XML file like this to know that the record was bad:

Quote:

Originally Posted by step

so I'd like to put it in the log like so:

Code:

if (!Copyfit(new MagnifyAttributes("text", 25, 400, 6, 72))){
	var warning = "Could not copyfit text in flow " + FusionPro.Composition.CurrentFlow.name;
    ReportWarning(warning);
    FusionPro.Composition.LogXMLMetadata('copyfit',warning);
}

Because if the record fails, you'll see that "status" attribute set to something other than zero. That's what you can key off of when you parse the XML log.

You can still write the metadata to the XML log if you want to, but it's already designed to do what you want, with those error-handling settings on the Advanced tab.

However, as I mentioned earlier, the ReportError function, while still not writing its message to the XML log, does set an error level for the record. So if you call that, it will set the error level to Medium, which will also cause the record to abort if you have it set to do so.

The other thing you can do, in FusionPro 9.2 or later, is call FusionPro.Composition.Abort. This takes three parameters, all optional:

errorMessage (string): The custom error message.
recordOnly (true/false): True to skip the record, false to abort the whole the composition (just like that second drop-down). Defaults to false.
errorCode (number): A custom error code, which either becomes the status for the record, or the return code for the composition, based on the "recordOnly" flag. Defaults to 1042 if not specified.

So, you can set that third parameter to whatever number you want, and that number will become the "status" code, for either the record or the composition, in your XML log file. You could even have multiple places to check for errors in your JavaScript rules, where each one calls FusionPro.Composition.Abort with your own custom error code, then the process that parses the XML log can use those error codes to determine what the failure mode was, instead of having to parse textual messages. That's a much more reliable way to handle errors in an automated system.

Note also that, if any records are skipped/aborted with an error, either via the error level from the Advanced tab or with a call to FusionPro.Composition.Abort, FusionPro also creates a "bad record" file (with the same name as the output file, but with "-bad" and the input file extension at the end) to contain all the records which failed. (The idea here is that you can easily see which records were bad, or even re-compose the job again with just those records and their data.)

So you should be able to use one of more of these strategies for "bad" record handling, without having to write a custom message to either log file.

That all said, if you want to collect up the job and post it, I can take a look and see why copyfitting isn't working as expected.

step · #3 July 31st, 2015, 04:16 PM

Thanks for the reply, Dan.

Quote: