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

Confusing behaviour of scale parameters #17

Closed
vytis opened this issue Apr 9, 2020 · 4 comments · Fixed by #44
Closed

Confusing behaviour of scale parameters #17

vytis opened this issue Apr 9, 2020 · 4 comments · Fixed by #44
Labels
enhancement New feature or request

Comments

@vytis
Copy link
Contributor

vytis commented Apr 9, 2020

I am trying out vpype and hit a problem early on. At first I thought it's a bug:

vpype read foo.svg scale 10cm 10cm write scaled.svg

However I should have actually used --to to achieve what I want:

vpype read foo.svg scale --to 10cm 10cm write scaled.svg

The resulting file initially was huge as the factor that it was scaled with is actually centimetres converted to px:

INFO:root:executing global processor `scale` (kwargs: {'scale': (377.95275590551176, 377.95275590551176), 'layer': -2, 'absolute': False, 'keep_proportions': False, 'origin_coords': ()})

There could be few things that would have helped me to see what goes wrong:

  1. scale would error out when passed size with units.
  2. scale would default to scale --to when passed size with units.
  3. It could be two separate commands.
@abey79
Copy link
Owner

abey79 commented Apr 9, 2020

Thanks for the feedback, this is very useful. I see how this could be confusing.

On several occasions I did use the ability to do (relative) scale with units in factors, especially when using script or writing plugins. This allows me to use arbitrary units when generating geometries (for example a regular grid whose cells have unit width and height) and subsequently scale it to a predictable physical size (the unit-cell grid, when scaled with scale 1cm 1cm, would then have 1cm-sized cells, irrespective of the number of cell). This (admittedly advanced) use-case leads me to reject (1) and, thus, (2).

Having a separate scaleto command (for the lack of a better name) would definitely make sense, and would be easy to implement. I further think than it should default to the keep proportion behaviour since its the most common use-case, with an option to tight fit. Would that make sense to you? Any proposal for the command name?

@vytis
Copy link
Contributor Author

vytis commented Apr 10, 2020

Makes sense, I didn't think of this use case.
So as I understand the --to parameter would be dropped and scaleto would then be the same as what scale --to is now? I don't have any preference on the naming to be honest...

@abey79
Copy link
Owner

abey79 commented Apr 10, 2020

Yes, scaleto would be the same as scale --to --keep-proportions, with an option to not keep proportions.

@abey79 abey79 added the enhancement New feature or request label Apr 10, 2020
abey79 added a commit that referenced this issue Jul 12, 2020
@abey79
Copy link
Owner

abey79 commented Jul 12, 2020

Further commit d2be51f to default to keeping proportions.

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

Successfully merging a pull request may close this issue.

2 participants