Summary
Page box sizes in the normalized PDF
's metadata are often defined with up to 8 decimals, to snap to the nearest available internal value of the application which creates the file. You don't have control over this.
E.g.: When you originally define a trim box height of 90mm, it gets saved as 89.99995978
mm.
Use case: You want to verify that the file which was submitted to the Automation Engine workflow, matches the expected size which is defined in your MIS or ERP system. The MIS or ERP system typically define a whole number value and not a number with many decimals.
This means you need to round the actual size value from the file's XMP
metadata to zero decimals. If not rounded, the SmartName will not find a match.
In this example, the Automation Engine Job Parameters (expected values taken from the MIS or ERP system) look like this:
But the value saved in the file is defined as this:

Symptoms
If your SmartName value is not rounded, a SmartName which checks if the normalized PDF
's metadata, egGr:vsize
is equal to your job's Height
parameter, will return that the values are not equal.
Because 89.99995978
is not equal to 90
.
Solution
In your XMP XPath SmartName definition, set the Format: option to As Number: No Decimals. This will round the value to the nearest whole number. So, 89.99995978
will be rounded to 90
and that matches with the value 90
from the job info.
The default format value is None
, which will keep the value as available in the normalized PDF
's XMP
metadata. A SmartName with the format None
will return the non-desired value as shown next to Result: in this screenshot:

When you change the Format to As Number, no decimals, the result will be rounded to 90
:

Use the above SmartName in your router task which verifies if the value equals the job parameter.