Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usability #33

Closed
Eitot opened this issue Dec 20, 2015 · 6 comments
Closed

Usability #33

Eitot opened this issue Dec 20, 2015 · 6 comments

Comments

@Eitot
Copy link
Contributor

Eitot commented Dec 20, 2015

Have you considered any simplifications or changes to the workflow? Currently, the minimum input is this:

scour -i /path/to/file.svg -o /path/to/newfile.svg

However, would it not be possible to imply the -i and -o by default? Like this:

scour /path/to/file.svg /path/to/newfile.svg

In addition and/or alternatively, why not make -o optional and automatically write the new file to the same directory, appended with a number, date and/or keyword to the file?

scour /path/to/file.svg

Ideally, I just want to type scour and drag and drop into the CLI. Moreover, I would actually like to see an option for scrubbing multiple files at once.

scour /path/to/file.svg /path/to/file2.svg /path/to/file3.svg

Any thoughts?

@Ede123
Copy link
Member

Ede123 commented Dec 29, 2015

Without having looked at the code and therefore the feasibility of the implementation I'd vote in favor of using "unnamed" command line parameters as input/output file names to save the -i and -o which is default for most command line programs.

I'd not recommend to add a suffix to the input file name in case the user omits an output file name since an "arbitrary" suffix is likely not to match the users requirements.
What we could think about is overwriting the input file if no output file name is specified but this might result in really ugly scenarios of data loss, so maybe we should just stick to the current behavior and require the user to provide a valid output file name.

@Eitot
Copy link
Contributor Author

Eitot commented Dec 30, 2015

I'd not recommend to add a suffix to the input file name in case the user omits an output file name since an "arbitrary" suffix is likely not to match the users requirements.

But it would be better than overwriting the input file, which I cannot recommend, based on my own experience with this program and others. Using an, as you call it, arbitrary suffix would be acceptable when the user does not define an output file name themselves. There could even be a default option for this. I’m just more concerned with easy drag and drop. :)

@Ede123
Copy link
Member

Ede123 commented Aug 16, 2016

This was fixed in 72c2ec8.
Scour still requires you to specify an output file name, otherwise output is written to stdout (so you could pipe or redirect it)

@Ede123 Ede123 closed this as completed Aug 16, 2016
@HEXcube
Copy link

HEXcube commented Jan 29, 2017

I use this bash command to workaround scour's hesitation to overwrite the input file:

for file in *.svg; do scour -i "$file" -o "$file"opt; mv -- "$file"opt "$file"; done

It cleans all the SVG files in current folder (not recursive though) and renames scour's output files to overwrite the original ones. I derived it from this answer on Unix StackExchange: Link to answer. In case if anybody needs it, this is the full command with all the scour options I use:

for file in *.svg; do scour -i "$file" -o "$file"opt --set-precision=5 --renderer-workaround --enable-viewboxing --indent=space --nindent=2 --strip-xml-space --enable-id-stripping --protect-ids-noninkscape; mv -- "$file"opt "$file"; done

@Ede123
Copy link
Member

Ede123 commented Jan 29, 2017

An option to replace the input file is currently tracked in #129.

@HEXcube
Copy link

HEXcube commented Jan 30, 2017

@Ede123 That's good news! 😃

If implemented, would simplify my command into:

for file in *.svg; do scour "$file" --in-place; done

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants