Different low-res files depending on file size - possible?

[patej]

Hi,

I would like to have a following flow:

1. high-res (HR) PDF comes in

2. if the HR PDF file size is under certain value (e.g. 500KB), move in straight into low-res (LR) output with possible renaming (this I have done)

3. if the HR is above the limit, then run a Pitstop action to make it a 100ppi low-res

4. if the LR size is now under the limit, then move it to low-res output

5. if the LR size is still above the limit, run a 72 ppi Pitstop action on the original HR file to create a smaller LR file

6. check LR size again and move to output if small enough

7. if the LR size is still above the limit, run a 40 ppi Pitstop action on the original HR file...



So is it possible to run a pitstop action with a file, check the output file's size and if it's too big, run another action with the original file. To get good quality low-res files you obviously cannot run several downsampling actions with the same low-res file, but you should use the high-res one.



I think it should be possible to write a script where the HR is copied to a temp location and then run these pitstop actions with size checks in between, but I'm not sure how to tackle this... Can you access pitstop actions through scripting? Do you have any ideas that could help me? Or just a plain "no it won't work"?



Best regards,

--patrik

[freddyp]

On the input folder you have two connections, one directly into the lowres folder and one to another folder for files that are too big.



From that folder you have two connections, one to a temp location (e.g. /somepath/tmp) so you get a copy of your file (add a "Recycle bin" after that), and one to PitStop Server with the action list to reduce the image resolution (also add the standard action list "Minimize file size" which will crop images, remove annotations, remove ICC profiles, etc).



After the processing by PitStop Server you again have two connections, one to the lowres folder, and one to (and here comes the trick) "Inject job" with which we will be picking up the original file! The quirky thing about "Inject job" is that the interesting properties are on the outgoing connection. There you set the "Inject" property to "Specific job" and in the "Job path" you set a single-line text with variables "/somepath/tmp/[Job.JobName]". After the inject you set another PitStop Server and it will process the original file instead of the already processed one.



And again, and again.



You could refine it further by doing a "Minimize file size" at the very beginning even before copying the file to the temp location, so you do not have that anymore afterwards, and who knows, it may be enough without resampling the images.



Freddy

[patej]

Huge thanks, Freddy! So that's what inject job is useful for..



I changed the flow according to your suggestions but unfortunately it cannot inject the original HR from the temp folder. Switch only says that "Failed to inject job: file or folder'serverfoldertmp-folderbigfiletest.pdf' does not exist". Any idea why this happens? The job path for "Specific job" is 'serverfoldertmp-folder[Job.Name]' and log says that "Variable [Job.Name] evaluated to 'bigfiletest.pdf'" so it should be OK. In Windows Explorer the HR file name in the tmp folder has, naturally, a unique name prefix and that is different that the incoming job's one, but that shouldn't be a problem because I use [Job.Name] as the variable..? You wrote that the job path variables should have "[Job.JobName]", but isn't that an invalid variable?



--patrik

[freddyp]

There are still a few other uses for "Inject job"!



Did you follow my suggestion to put a "Recycle bin" after the temp folder? That was just an idea that I did not test and now it is coming back at me . The fact that your file still has the unique ID messes it up of course. When you remove the recycle bin and you set to strip the unique ID all should be well.



Here is an alternative so you do not have to strip the unique ID. In the element where you send the HR file to the temp folder you set "Attach job state" to _[Job.UniqueNamePrefix]_[Job.JobName]. In this way you remember the original job with its prefix. In the inject you then use [Job.JobState] and all will be well.



Another thing that I noticed now that I tested it with the recycle bin in place: put a "Hold job" before the "Recycle bin" or Switch will not find the file to inject either .



Freddy

[patej]

Hi Freddy,

Thanks, the job state sounds good, I'll try that once I get a couple of things out of my hands first.



Yes, I realized the same thing with the Hold job before Recycle Bin and have it there already.



Thanks again for your fast replies and helpful tips,

--patrik

[patej]

Hi Freddy,

Thanks for your tips, I got it working, somewhat... Like you said, the Recycle bin was the problem because the files in the temp folder still had their unique ID's. So removing the bin and having the folder strip the id's solved it.



However, I would need the Recycle bin there to keep the folder clean and your suggestion to use the Job State sounded like a good solution, but I just couldn't get it to work. What am I doing wrong?

1. in the folder, that has a connection out to the temp folder and to the pitstop configurator, has "Attach job state" as _[Job.UniqueNamePrefix]_[Job.Name].

2. the connetion out from the Inject job has [Job.JobState] as its variable --> Switch still says it can't find the file.



Inject job seems to look for only file names so how should it be able pick the right job by it's saved job state? The file in temp folder has got a new name after all. Or is the only solution to write a script that loops through temp folder's files and compares with their job states? I also tried to have Inject job's "Inject" as Job repository, input the temp folders path to repository and the same JobState info in to job name.



--patrik

[freddyp]

Hi Patrik,



for me it works fine, so there is something you are doing wrong. There is one thing that strikes me as a possible cause. You write that inject job has [Job.JobState] as its variable. Are you just using that variable? Without the path? Have a look at my first reply:



There you set the "Inject" property to "Specific job" and in the "Job path" you set a single-line text with variables "/somepath/tmp/[Job.JobName]".




Afterwards I wrote to use [Job.JobState] without mentioning again that it should be part of the path.



Freddy

[patej]

Hi,

Sorry I explained myself a bit confusingly, yes, I tried with the path in the variable as well, but I also tried to have the "Job repository" in the Inject job so there I selected the path in the job repository part, so then the variable should need only the "[Job.JobState]", shouldn't it? In both cases the error message saying that Switch could not find the job has the correct path of "/somefolder/tmp/jobname.pdf".



But the thing I don't understand here is that how can Inject job find the right job from the temp folder because the JobState it compares with is the ID+name of the original HR file, not the ID+name of the HR file copied into the temp folder. So this is how I've understood it goes (and why it doesn't work):

1. HR file has an ID (e.g. 12345) and arrives to folder 1

2. the JobState "_[Job.UniqueNamePrefix]_[Job.Name]" is stored to the HR file

3. the HR file is copied to the temp folder where it gets a new ID (e.g. 12346) and to Pitstop connector where it also gets a new ID (e.g. 12347). Both of these files have still the original JobState stored.

4. Inject job looks for the original JobState (e.g. _12345_jobname.pdf) in the temp folder, but cannot find it because the jobname.pdf is named _12346_jobname.pdf according to its new ID.



So I don't understand what is the logic behind the JobState: how should Inject job be able to find the right file. Could you possibly send me your example flow?



--patrik

[freddyp]

The unique ID of a file does not change because it is moved to a different folder. It does not even change when it is processed, but this is only true when the file is processed in a straight line.



When you have two connections that the file has to follow the original ID will follow one, and a new ID will follow the other. The only logical explanation I could find was that in my case the original ID went to the temp folder and the new ID to PitStop Server. This is why the original ID could be picked up later on. And that in your case the original ID goes to PitStop Server and the new ID to the temp folder.



I wondered why that would be and I experimented a little bit with the order in which connections are drawn and elements are added and now my flow is broken as well & . And I cannot get it fixed anymore! Definitely . The conclusion from this is that there is a relationship between how unique ID's are attributed and the way in which the flow is built, but it is does not seem to be predictable. I got lucky, you did not, and now we are both unlucky .



Until further notice I am afraid the conclusion is: stop the flow at the temp folder, strip the unique ID, use [Job.JobName] in the inject and clean the temp folder in a different way.



Freddy

[patej]

OK, thanks for the clarification! Now we at least now where the problem lies, a pity though that there does not seem to be a solid solution. I'll try playing around with it then, now that I know the cause for the problem. The flow has worked fine these two days as it is, so it's not a huge problem but keeping the temp folder clean naturally creates some unneccessary hassle.



Sounds odd to not be able to predict how the unique ID's are assigned because that might affect a lot of things in different flows. I think this should be reported to Enfocus to be fixed some way. This actually reminds me of Esko's Artios Cad and the cut directions for the knives it assigns to different lines, which some times come out in quite random logic. There, however, is a tool to change the direction of the lines so probably something similar could be done here..?



--patrik