Page 3 of 4
Re: Typos in the command line option page for V 6
Posted: 2016-01-06T15:41:42-07:00
by 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?
Re: Typos in the command line option page for V 6
Posted: 2016-01-06T16:02:17-07:00
by snibgo
Originally "Simple", but now "Sophisticated".
Re: Typos in the command line option page for V 6
Posted: 2016-01-07T17:46:32-07:00
by 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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-07T17:51:51-07:00
by 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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-25T18:50:23-07:00
by 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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-25T18:56:47-07:00
by snibgo
28 lines? Is that all? I'd be interested in seeing it.
Re: Typos in the command line option page for V 6
Posted: 2016-01-25T20:41:45-07:00
by 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]+
Re: Typos in the command line option page for V 6
Posted: 2016-01-25T20:53:32-07:00
by ronsavage
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T16:45:07-07:00
by ronsavage
BTW: Is label:"Some text" the deprecated form of -label "Some text"?
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T17:20:37-07:00
by 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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T20:48:44-07:00
by ronsavage
Ahh. OK. Thanx.
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T21:11:18-07:00
by 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?
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T21:25:06-07:00
by 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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T22:19:33-07:00
by fmw42
ronsavage wrote: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.
Re: Typos in the command line option page for V 6
Posted: 2016-01-30T22:26:25-07:00
by fmw42
ronsavage wrote: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.