Why did my tFLOW preflight accept an uploaded image from Pressero that was the wrong size even though Check Size is enabled?

Question: Why did my tFLOW preflight script accept an uploaded image from Pressero that was the wrong size even though Check Size is enabled?
It can be complicated. Scalable sizing, file aspect ratio, image dpi, file type, and Pressero file upload settings can all play a role in what's delivered to tFLOW and whether "the wrong size" image is actually the right size (or at least OK). For example
  • If an image is scalable up or down to the desired size while still meeting your dpi requirements, is it acceptable or still "wrong size"?
  • If an image has bleed that's greater than the trimmed "correct size", is the image acceptable or still "wrong size"?
  • If you set Pressero uploads to a specific height and width, turn on scaling and the aspect ratio of the customers uploaded file matches the desired size, is the perfectly scaled image Pressero delivers to tFLOW acceptable or  still "the wrong size"?
Most would say the image is acceptable in these scenarios. And so does tFLOW.
Let's take a look at these in more detail:
tFLOW Size Presets vs. Pressero Size Attributes. If your tFLOW product script has "check size" enabled (and you've pre-specified a size), or the tFLOW check size option uses customer-specified sizes via Pressero product or pricing attributes, such as:
tfall_job_print_width = 24
tfall_job_print_height = 36
Check Document Size = Yes
then enforcement of the preflight file size check depends on the type of file that's uploaded, and the Pressero settings used. More on that below...
Let's assume that you want to enforce a file size of 24" W x 36" H. You either have the tFLOW product preset to use those dimensions for "check size", or the Pressero attributes above are sent to tFLOW as height and width variables. (More on tFLOW Variables here: https://support.aleyant.com/kb/a1344/tflow-documentation-07a_-variables.aspx) The customer entered a height and width when ordering in Pressero and tFLOW can use those instead of a preset.
Aspect Ratio, Scaling, DPI. Maybe you also want to enforce a minimum resolution of 150 dpi. If the customer sends a 12" W x 18" H file via Pressero at 300 dpi, when the file is scaled up to meet the 24" x 36" requirement it will have 150 dpi, passing both the size and resolution checks.
Files with Bleed. And what about files with bleed? A 24" x 36" PDF file with 1/8" bleeds may have a trim size (final size) of 24" x 36", but a bleed size of 24.25" x 36.25". When tFLOW enforces the "Check Size" option, it's looking at the PDF's Trim Size page box of 24" x 36". Even though the file with bleed is larger, the file will pass the test.
JPG Files. Now let's say your client uploads a 40" x 60" JPG file at 150 dpi. It should fail preflight for size (too big!) and display an error, right?
Not exactly. Unlike a PDF, JPG files and other raster image files don't come with the Page Boxes feature like PDF files do. Page boxes define a PDF's media size, bleed size, trim size, and crop size.
Because JPG files don't contain these page boxes data, a 40" x 60" JPG file sent to a tFLOW product script directly (not through Pressero), tFLOW would enforce the 24" x 36" size and the file would fail preflight.
So when Pressero sends it over, how could the same file end up passing instead?
The short answer is because Pressero will either scale or stretch the file to the size specified in the Pressero product's file upload settings. When setting up a product in Pressero to include a file upload field, there's a check box called "Show scaled preview" that works with the values you set for Width and Height. See the screenshot below.
If you set the Width, Height values, and if "Show scaled preview" is checked, then when a file is uploaded, it will be scaled without distortion to fit the page size given here. If not checked, the preview will be stretched to match the page size exactly. This scaled file is what gets passed to tFLOW.
So in our example above, if you enforce a size of 24" x 36" at 150 dpi in tFLOW, but a site user uploads a 40" x 60" file at 150 dpi in Pressero, what arrives in tFLOW from Pressero is actually a 24" x 36" file at 250 dpi. The only reason that it did not fail preflight is because 40" x 60" and 24" x 36" have the exact same aspect ratio of 2:3. 40" x 60" scales down perfectly to 24"x36". If the original JPG file did not have dimensions that matched this ratio (say 45"x56"), and you had "Show scaled preview" checked in the product's file upload setup in Pressero, then the file would have arrived at a scaled size in tFLOW and because the scaled size didn't match the size being enforced in tFLOW it would fail preflight.
So what happens if Pressero's "Show scaled preview" is unchecked ? If the file had a different ratio than 2:3, Pressero would stretched the image to match the final size exactly. It would be distorted, but the exact dimensions. When it arrived in tFLOW, it would not fail because Pressero stretched the image to match the final size exactly. A distorted image is likely not going to be acceptable to the customer, so having "Show scaled preview" checked is the lesser of evils and more likely to deliver the desired size check results.
Of course the best thing to do when working with file uploads in Pressero products is to help your clients adopt a PDF workflow. Embed a quick how to "explainer video" on the product, and or have a link to a How to save as PDF" FAQ you added to the store. This way file sizing can be enforced in a more straight-forward manner. Not every site user will jump on board of course and sometimes JPGs and other raster image formats may be all that the site user has available. It's our recommendation that you work to try and make these situations the exception instead of the rule, to help you maintain a workflow that's as touch-less as possible. 
Related Articles: