Typos in the command line option page for V 6

[fmw42]

In command line, you could just create a variable for the command and then use the variable

convert input $variable output

I do not know if that fits with what you want. But thanks for the explanation. Neat that you are creating a GUI driven IM.

SWIM for Standalone Windows IM?

[snibgo]

Originally "Simple", but now "Sophisticated".

[ronsavage]

An update on my Perl module. It's working well enough on options and their parameters.
Now I'm just adding support for handling the trailing output file name as a special case of the latter.
After that, a little cleaning up and I'll release it.
The first practical use I see is to accept an IM -crop and apply it to an image managed by Imager.pm.

[ronsavage]

For those intrigued, the Marpa-style BNF [1] is 425 lines, double-spaced for my personal preference making it 850.
[1] https://metacpan.org/pod/distribution/M ... ss/DSL.pod where DSL [2] is domain-specific language.
[2] https://en.wikipedia.org/wiki/Domain-specific_language.

[ronsavage]

An update. I originally wrote the BNF to treat each action (-size etc) separately. After re-writing the BNF many times to treat actions uniformly, I got the BNF down to 28 lines.
But, post-processing the output of the parsing engine (Marpa::R2) to handle special cases caused me to write what I feel is too much code, so I'm switching from Marpa to Set:FA::Element. The FA is Finite Automaton, so yes, it'll be a state machine approach this time.

[snibgo]

28 lines? Is that all? I'd be interested in seeing it.

[ronsavage]

Here it is:

Code: Select all

:default				::= action => [values]

#lexeme default			= latm => 1		# Longest Acceptable Token Match.

# G1 rules in top-down order.

:start					::= command_and_options

command_and_options		::= command_name input_file_name rule_set

command_name			::= 'convert'						action => command
							| 'mogrify'						action => command

input_file_name			::= string			rank => 1		action => input_file
input_file_name			::=					rank => 0		action => input_file

rule_set				::= rule*

rule					::= action_set
							| close_parenthesis				action => close_parenthesis
							| open_parenthesis				action => open_parenthesis

action_set				::= sign action_name parameter_set	action => action_set
							| operator						action => operator

action_name				::= string

operator				::= operator_name

parameter_set			::= string*

# L0 rules (lexemes) in alphabetical order.

operator_name			~ operator_name_char+
operator_name_char		~ [^-+@\(\)\s0-9]

close_parenthesis		~ ')'

open_parenthesis		~ '('

sign					~ [-+]

string					~ string_char+
string_char				~ [^-+"\(\)\s]

# L0 rules (lexemes) for the boilerplate.

:discard				~ whitespace
whitespace				~ [\s]+

[ronsavage]

And here it is as space-filled gist:

https://gist.github.com/ronsavage/eaa52bd0ab619cfc467b

[ronsavage]

BTW: Is label:"Some text" the deprecated form of -label "Some text"?

[snibgo]

No, they do different things.

Anything with a colon suffix (eg xc: and label:) creates a new image, adding it to the current list.

Anything prefixed with a minus (eg -label and -blur) either operates on images, or is a setting that modifies an operation. Most operators operate on all the images in the current list, so I expect (but haven't verified) that "-label" changes the metadata of all images in the list. It doesn't modify the actual images.

[ronsavage]

Ahh. OK. Thanx.

[ronsavage]

On this page: http://imagemagick.org/script/command-l ... essing.php
there is an option: area@ Resize image to have specified area in pixels. Aspect ratio is preserved.
But the example uses a different syntax: convert logo: -resize '@10000' wiz10000.png.
Should the latter read convert logo: -resize '10000@' wiz10000.png?

[ronsavage]

And at the same point:
{size}{offset} Specifying the offset (default is +0+0). Below, {size} refers to any of the forms above.
{size}{+-}x{+-}y Horizontal and vertical offsets x and y, specified in pixels. Signs are required for both. Offsets are affected by ‑gravity setting. Offsets are not affected by % or other size operators.

Couldn't the first one be deleted? It just summarizes the second. If so, it's text could be added to the start of the second.

[fmw42]

On this page: http://imagemagick.org/script/command-l ... essing.php
there is an option: area@ Resize image to have specified area in pixels. Aspect ratio is preserved.
But the example uses a different syntax: convert logo: -resize '@10000' wiz10000.png.
Should the latter read convert logo: -resize '10000@' wiz10000.png?

It does not matter whether the @ is before or after the area. Both produce the same output. However, it should be changed to 1000@ to be consistent with the descriptions earlier.

[fmw42]

And at the same point:
{size}{offset} Specifying the offset (default is +0+0). Below, {size} refers to any of the forms above.
{size}{+-}x{+-}y Horizontal and vertical offsets x and y, specified in pixels. Signs are required for both. Offsets are affected by ‑gravity setting. Offsets are not affected by % or other size operators.

Couldn't the first one be deleted? It just summarizes the second. If so, it's text could be added to the start of the second.

Conceivably they could be combined into one, but not the first simply delete, since it includes the default value for offset. I think it is there simply to provide a way to explain the default if no offset is provided.