Danny,

You aren't alone in your puzzlement. Through version 7, there are some idiosyncracies that I haven't noodled out yet (time v. effort), but have found a "best practices" routine for most of my automation techniques.

why an action for the resize and another for the SFTW?

Part of my "best practices". Functionally, there's no reason not to have a single, all inclusive action. I find the actions pallet a nightmare to naviate so I organize actions according to functions: resizing, saving, etc and in button mode use a dummy action name as a divider within a set. For me, it's easier to create separate steps to avoid troubleshooting difficulties since the actions are broken into smaller chunks - just look at the sfw action. Scrolling your action pallet to find a specific issue is, IMO, ridiculous, so I like to break them up into manageable chunks and then "nest" actions.

An added benefit is that if you organize your actions well (and most of us don't), you can call previously created actions without having to recreate them. For example. I have an action that does what I call a standard "autolevels, gaussian blur, unsharp mask". After that I have several routines that call that function first, then perform other tasks - maybe high pass sharpening, or an edge mask followed by a blur and then levels adjustment and then a sharpen. But my first routine is the AL/GB/USM. I do the same thing with resizing to a specific ppi - first resize, then run my al/gb/usm, then optionally run other actions. Since these are common routines, I find it easier to call them and nest them to reduce clutter and make troubleshooting easier.

Other than organizationally, there is usually no inherent benefit. I have found fewer problems with nesting actions but I cannot say why, save for the possibility that it's easier to manage and thus troubleshoot.

That's a long-winded way to say that it may be simply personal preference.

in my tests 'Override "Save As" Commands' doesn't seem to have the same desired effect (preserve file characteristics, but ignore file name and folder recorded in the command) as it does on a vanilla, unchecked (no dialog) Save As command.

Override Save As functionally passes saving routines from the action to the Batch dialog box. That includes filename AND location. With SFW, however, it DOES NOT pass this function to the Batch dialog. Since SFW is an Export function, it behaves badly in terms of consistency as it relates to batching. The destination used is whatever the action calls and the file naming remains unaffected by the batch dialog.

I presume that the reason for this is that since SFW is an export command, and offers the opportunity to be mac or unix compliant, it takes control to make sure it puts in the dashes where %20 would exist to represent a space. I guess it's a situation of which rules to follow, and the developers erred on the side of "if you use sfw, then let it have control". <shrug>.

So why did I tell him to check the box and optionally choose a naming convention? Mostly habit - the naming convention I should have known better, but the Override Save As box is simply habit. Without it checked, file saving routines remain in the domain of the action, and I don't usually do that. So it was really an error on my part, although not with any real negative consequences.

Im getting a Save for Web dialog for each image, even with the show dialog modal control turned off. Ditto when Save for Web is inserted via Insert Menu Item.

This I cannot understand. I have heard reports of it from others, and even reproduced it once. My thought at the time was that it may have something to do with whether you nest the SFW action or simply have it part of a long action. I just tested it, and that's not true. Either nested or as part of a long action sequence, I do NOT get the SFW dialog.

I wonder if when you are testing, when you record the action, do you bring it all the way to completion? That is, you actually save the file while recording, then stop the action? That's what I do.

In sum, the behavior of SFW as it relates to batching is buggy - that does NOT mean it has bugs, it's just that there are some overlapping rule sets that are either not documented or that I simply don't understand. That's about as much as I can offer, but am happy to work with you on the SFW dialog issue. That is to say, If you really want me to reproduce it again, I will work on it and see if I can't find out why it shows in some situations but not others.

Peace,
Tony

lin_jiang

Replied in the following topics

Batch Processing: Save for Web