Jump to content

OnCopyfit on Server


Recommended Posts

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:

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:

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:

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:

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:

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!

Link to comment
Share on other sites

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.

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.

With that in mind, I tried this:

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...

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.

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...

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:

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:

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

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.

Link to comment
Share on other sites

Thanks for the reply, Dan.

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.

Well yeah, I wasn't saying it doesn't work in Server – it obviously does. I was just saying that it seemed like the way the "Copyfit" function validated on the Server might be different. I guess the way I rationalized that to myself was: "Well, it's not like it doesn't say the text didn't fit. It just doesn't print the error because I'm not watching the composition run from the dialog box on my desktop."

That output looks basically the same to me.

What? It printed "fits" right above the message telling me it doesn't fit. So, that made me think it always validated as true on the Server.

 

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?

I created an Assets.dat file when I collected my template and it's in the same directory as my template, but I have not specifically called it from the command line if that's what you're asking. I'm running the file like this:

C:
CD C:\Program Files (x86)\PTI\FusionPro\
FusionPro "\\server\path\to\templates\test\data.csv" "\\server\path\to\templates\test\test.dif" "\\server\path\to\templates\test\test-o.cfg" "\\server\path\to\templates\test\output.pdf"

 

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).

That's how I was hoping that worked.

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.)

Can you give an example of a "severe" error? If a "medium" error is something reported by "ReportError," is it correct to assume that a minor error is something reported with "ReportWarning?" And with that assumption in mind, does that mean that "medium" and "minor" errors can only be generated if I were to physically call them from code or can FP also throw those?

 

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:

 

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.

That's precisely it except I'm not sure I want to fail the record as much as I want to be prompted to check the log and find out what didn't copyfit. There are some cases where the truncated text isn't necessary and I don't want to have to re-run the entire job in an instance like that.

 

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.

That sounds neat. I definitely like the ability to add custom error codes that seems very helpful I just want to do so without skipping the record or aborting the job.

 

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.)

That's a good idea too but a lot of our jobs (this one in particular) is pre-sorted. So if a record(s) get deemed as "bad" it would become a headache for our kitting department.

 

Anyway, again, thanks for the feedback and the ideas. I have been working on a test file to upload to the forum (the actual file is very large and contains a bunch of customer sensitive data that I don't feel comfortable uploading) but I haven't been able to reproduce the problem. Which...I guess is good? Now I just have to figure out what it is about my actual template that's different from my testing one.

Link to comment
Share on other sites

Well yeah, I wasn't saying it doesn't work in Server – it obviously does. I was just saying that it seemed like the way the "Copyfit" function validated on the Server might be different.

With computers, it's always more relevant to say that something works "differently" than it is to so that something "worked" or not. But still, if it worked differently like that between Desktop and Server for most jobs, we would have heard about it.

I guess the way I rationalized that to myself was: "Well, it's not like it doesn't say the text didn't fit. It just doesn't print the error because I'm not watching the composition run from the dialog box on my desktop."

Of course there's no Composition Status dialog for a Server composition (though Server will write to the Command Prompt window). But the log file should be basically the same.

What? It printed "fits" right above the message telling me it doesn't fit. So, that made me think it always validated as true on the Server.

Obviously it doesn't always validate as true, at least not with all templates. But I was saying that it looked basically the same because you still got the message from the composition engine about the line not fitting.

I created an Assets.dat file when I collected my template and it's in the same directory as my template, but I have not specifically called it from the command line if that's what you're asking

No, I meant it should just be in the same folder. It seems that it's not a font issue.

Can you give an example of a "severe" error?

Sure. Some examples are: failed to open the input data file, or the format (DIF) file, or the CFG file; failed to write the output file; missing a graphic resource; and other various problems with malformed or missing files or resources.

If a "medium" error is something reported by "ReportError," is it correct to assume that a minor error is something reported with "ReportWarning?"

No. ReportWarning doesn't raise an error status.

And with that assumption in mind, does that mean that "medium" and "minor" errors can only be generated if I were to physically call them from code

No.

or can FP also throw those?

Yes. Most of the errors are "internal" and come from FusionPro itself.

That's precisely it except I'm not sure I want to fail the record as much as I want to be prompted to check the log and find out what didn't copyfit. There are some cases where the truncated text isn't necessary and I don't want to have to re-run the entire job in an instance like that.

That sounds like something that could be automated, so that you don't need that manual step.

That sounds neat. I definitely like the ability to add custom error codes that seems very helpful I just want to do so without skipping the record or aborting the job.

I'm not sure what a custom error code means, if there's no actual error state for the either the record or the job. But still, if you just want to add a note to the log file, it's still probably better to add it as metadata to the XML log than to add "plain" text to the .msg file.

That's a good idea too but a lot of our jobs (this one in particular) is pre-sorted. So if a record(s) get deemed as "bad" it would become a headache for our kitting department.

It's my understanding that the concept of "bad" records which need to be reprinted for one reason or another, and that there's a separate "exception" workflow to handle them, even with presorted data, is a standard one in the printing industry.

Anyway, again, thanks for the feedback and the ideas. I have been working on a test file to upload to the forum (the actual file is very large and contains a bunch of customer sensitive data that I don't feel comfortable uploading) but I haven't been able to reproduce the problem. Which...I guess is good? Now I just have to figure out what it is about my actual template that's different from my testing one.

That is the $64,000 question. Give me something to reproduce and I'll definitely analyze it.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...