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=filenameThe 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