Repository: beetbox/beets

Issue:
ImageMagick applies maxwidth to longest edge instead of to width
The [current invocation](https://github.com/beetbox/beets/blob/2120cf68c61649c22c14f20d83bd28d758720557/beets/util/artresizer.py#L96-L100) of ImageMagick applies the ```maxwidth``` parameter of ```fetchart``` to an image's longer edge instead of to its width. Possible solution suggested by Adrian [on the forum](https://discourse.beets.io/t/fetchart-taming-cover-art-resolution/206/12?u=dorade).





Discussion:
Thank you for the summary! I'm marking this as a "bitesize" bug because I think it should be a good entry point for anyone looking to get started contributing to beets.
Quoting the [ImageMagick documentation](http://www.imagemagick.org/Usage/resize/#shrink) linked to in the forum

>The Only Shrink Flag ('>' flag) is a special character in both UNIX Shell and in Window batch scripts, and you will need to escape that character (using backslash '\>' in shell, and '^>' in windows batch)

> As of IM v6.3.8-3 IM now has a new geometry option flag '^' which is used to resize the image based on the smallest fitting dimension.

and noting the [inline comment](https://github.com/beetbox/beets/blob/2120cf68c61649c22c14f20d83bd28d758720557/beets/util/artresizer.py#L91-L94)
```
# "-resize widthxheight>" shrinks images with dimension(s) larger
# than the corresponding width and/or height dimension(s). The >
# "only shrink" flag is prefixed by ^ escape char for Windows
# compatibility.
```
the fix might not be as obvious. The way I read this (without having done any testing/git blame myself)
- we do not want to drop the `>` flag since that would upscale small pictures
- the issue came about because the `^` flag was only introduced after our ImageMagick invocation was written. Unfortunately, that flag collides with the `^` escape character on Windows.

@translit, am I correct assuming that you ran into this on Linux and not Windows?

Unless there's another way to escape this syntax (quotes? I've really got no clue about Windows shell), it might be necessary to distinguish Unix-based systems and Windows when constructing the command line. Ideally, there would be a test for each of the architectures.
Aha! Thanks for catching the potential pitfall about small images.

However, my best guess is that escaping for the shell is not a problem here. Specifically, we’re using the `subprocess` interface, which accepts a list of arguments and passes them directly to the executable in question—without passing through any shell. This certainly would be a problem if we were composing a flat string and sending it to `os.system`, but fortunately we’re not doing that.
@wordofglass No, I'm on macOS. But that should be as good as Linux for our purpose, I guess.

Resolving patch:
diff --git a/beets/util/artresizer.py b/beets/util/artresizer.py
--- a/beets/util/artresizer.py
+++ b/beets/util/artresizer.py
@@ -88,14 +88,13 @@ def im_resize(maxwidth, path_in, path_out=None):
     log.debug(u'artresizer: ImageMagick resizing {0} to {1}',
               util.displayable_path(path_in), util.displayable_path(path_out))
 
-    # "-resize widthxheight>" shrinks images with dimension(s) larger
-    # than the corresponding width and/or height dimension(s). The >
-    # "only shrink" flag is prefixed by ^ escape char for Windows
-    # compatibility.
+    # "-resize WIDTHx>" shrinks images with the width larger
+    # than the given width while maintaining the aspect ratio
+    # with regards to the height.
     try:
         util.command_output([
             'convert', util.syspath(path_in, prefix=False),
-            '-resize', '{0}x^>'.format(maxwidth),
+            '-resize', '{0}x>'.format(maxwidth),
             util.syspath(path_out, prefix=False),
         ])
     except subprocess.CalledProcessError:


Test patch: