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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel