Yes, a config file might be a good solution. Though I think you forgot the option to specify the the output file name.
So I think the parameters should rather look something like this:

  --export=OUTPUTFILENAME --export-config=CONFIGFILENAME

As people may surely want to convert multiple files using the same config the name of the output file should stay a command line parameter.

Also I wonder why different --export-<file type> parameters where introduced. This makes it hard to cover all supported export file types and the type could simply be derived from the extension of the given output file name. Only in case of conflicting file extensions you'd need an extra parameter to distinguish the type. I.e. something like

  --export-type=FILETYPE

or

  --export-method=FILETYPE

as you were suggesting 'method' for that.

Though changing the existing parameters and introducing a help parameter is actually out of the scope of the defining a config file for the export options. So --export-text-to-path would stay untouched initially. I'll kick off separate threads for tightening up the existing parameters and introducing a help parameter.

So as a first step only the new --export-config parameter should be introduced.
So instead of having to write

  inkscape --export-png=out.png --export-width=100 --export-height=100
      --export-background=#000000 --export-area-page

you would have

  inkscape --export-png=out.png --export-config=config.cfg

where the config.cfg looks like

width=100
height=100
background=#000000
area=page

The names for the new config options still need to be discussed. The important point is to keep a common syntax for them. Though I'd vote for writing full names as boolean values or use 0 and 1, e.g.

  textToPath=true

or

  textToPath=1

Options not defined would be set to a proper default, not the stored value, to avoid confusion.

Sebastian

On 8 January 2015 at 18:42, mathog <mathog@...1176...> wrote:
On 08-Jan-2015 04:40, Diego Nuñez wrote:
> I also agree with Sebastian, that an option for setting that directly
> in
> the command line would be better and cleaner.

Ok, but...

There are kind of a lot of them (11 at present), and many of them don't
have descriptions that lend themselves very well to single letter or
single word command line options.  These are the descriptions:

"Convert texts to paths"
"Map Unicode to Symbol font"
"Map Unicode to Wingdings"
"Map Unicode to Zapf Dingbats"
"Use MS Unicode PUA
"Compensate for PPT font bug"
"Convert dashed/dotted lines to single lines"
"Convert gradients to colored polygon series"
"Use native rectangular linear gradients"
"Map all fill patterns to standard EMF hatches"
"Ignore image rotations"

And these are the internal variable names potentially similar
to the command line names, but I think not very easy to understand.
Note that almost all of these are present to work around various
PowerPoint bugs, whether or not the names indicate
that:

textToPath
TnrToSymbol
TnrToWingdings
TnrToZapfDingbats
UsePUA
FixPPTCharPos
FixPPTDashLine
FixPPTGrad2Polys
FixPPTLinGrad
FixPPTPatternAsHatch
FixImageRot

Other input/output extensions will also have options, and they most
likely will not overlap very much.  If we place all of this at the same
parameter level as --file we risk burying the most important command
line options in detritus on an "inkscape -h".  Also there are already
quite a lot of command line options.

This issue comes up a lot in DNA assembly and other complex programs,
where there are tons of possible parameters, and the common method of
solving it is to use a parameter file.  Perhaps we should do the same
thing here?  For instance, this is a generic
export, where all parameters are in the filename:

    --export=filename

The named file would include lines like:

method=emf
textToPath=F
TnrToSymbol=T
TnrToWingdings=T
TnrToZapfDingbats=T
UsePUA=T
FixPPTDashLine=F

"method" here replaces --export-emf on the command line, and the
rest of them are export parameters. Any not named would default to the
stored settings?  Also  perhaps:

   --export-help=emf

would print a help message listing all the parameters for that
export type, and I suppose also the current default values.

So, for instance, a user would interact with the program like this:

inkscape --export-help
# with no parameter, lists all export types
inkscape --export-help=emf
# reads message and learns the options, creates a file for
# a certain task with an editor, then
inkscape --export=ParamsForEmfFile.txt --file=in.svg

Ditto for a generic import, I suppose.

I know that we already have some command line parameters like:

   --export-text-to-path

but this example shows that these are actually problematic, since there
is no way to set the program to negate that value.

Also, whoever maintains this page:

   https://inkscape.org/doc/inkscape-man.html

it seems a little out of date, for instance, it doesn't list the emf/wmf
options.

Regards,

David Mathog
mathog@...1176...
Manager, Sequence Analysis Facility, Biology Division, Caltech

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel@...1794...s.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel