1) Placeholders are totally fine
as this is anyhow expert matter. Even preferred. Provide maximum flexibility: Custom Order among themselves, combination with free text, etc.
Worked in GC 11.6.1 (5479).
2) Now in your implementation placeholder-insertion is a workflow-step within a batch. A good first implementation certainly! Don't get me wrong, very glad that you did that right away! But this ofc means you must include an "Add text to Filename" step into each batch where you want it applied. Too much management effort, which I already originally foresaw.
Hence I had proposed my complimentary feature QuickConvert dropdown menu gets options for placeholder-insertion into the names of the output files and/or folder
This would ofc be much more elegant: Way less management overhead, more flexibility. UX wise a Win:Win. Because you would define all placeholder inclusions centrally on its own or even as presets. Used in combination with any batch. And with any of the output file formats.
The power of permutations! 5 image processing batches + 3 placeholder-insertion presets + 5 file formats presets = 13 presets to manage. Instead of 5 x 3 x 5 = 75 all-in-one presets to manage all their possible permutations. And 75 to check/update each time.
It's basically what you have done already for the file formats. "Change file format" can be a workflow-step within a batch. But file format choice is offered as a top level standalone entry in the Quick Convert dropdown, which then overrides any format changes contained in a batch as a step.
Same could be done for the Placeholder-Insertion. Hence better a dedicated "Insert Placeholders to filename" workflow-step instead of "Add text to filename". B/c if you then use the Placeholder Insertion of the Quick Convert Dropdown (either one for all (as on my mockups) or even presets (with the issue of the dropdown menu overally getting even longer...) then GC would deactivate any "Insert Placeholders to filename" workflow-steps encountered inside batches.
3) Also on some particular placeholders there was a misunderstanding:
a) &width; and &height; are the effective width and height coming out of the batch.
This is also a good option to have. So anyways please keep them.
b) But what I wanted to express in the batch name via tokens is user intent. So often only one dimension (certain height or certain width) and the intended unit (pixels, percent, centimeter, inch).
So for maximum naming flexibility we would ideally need these tokens:
The number as an integer or decimal number, e.g.: 50 ; 127.34
—"— but numbers are padded to 3 digits
—"— but numbers are padded to 4 digits
—"— but numbers are padded to 5 digits
cm ; in ; % ; empty string (no untis) for pixels (they are implicit, because if there is a number with no units stated in an image or video filename it is pixels as the most common used metrics in digital images)
cm in px pc Units as 2 alphanumerical characters for maximum filename compatibility and uniformity.
If width was scaled (indicated by the first X in the placeholder name) then it returns "x"
—"— then it returns "X"
—"— then it returns "w"
—"— then it returns "W"
—"— then it returns "width"
—"— then it returns "Width"
If height was scaled (the first Y in the placeholder name) then it returns "Y"
—"— then it returns "Y"
—"— then it returns "h"
—"— then it returns "H"
—"— then it returns "height"
—"— then it returns "Height"
—"— then it returns "x"
—"— then it returns "X"
- The latter two can make sense where the position of the x before or after the number is desired.
- Already seen in the wild, i.e. ImageMagick uses that notation in all its geometry arguments.
produces "1024x" if "scaled to width of 1024"
produces "x800" if "scaled to height of 800"
- If a batch contains no scaling operations then all $scale… placeholder produce nothing and any "Insert Placeholders to filename" steps are discarded as a whole (including static free text)
- As soon as the "[ ] Proportional" option for scaling is toggled OFF then all &scaleX… and &scaleY… placeholders return null and &scale; produces XXXXxYYYY. Still &scaleUnit; would return.
So if used wisely then with a clever placeholder pattern you can create very uniform filenames.