Add support for new XXHDPI (480dpi) which is 1.5x XHDPI.

Determine if this should replace XHDPI as default folder, or wait for more devices/adoption. If it does not replace default behaviour a flag should be created that allows execution from within xxhdpi folder, rather than xhdpi.

Summary

• I'd like to add support for MSIE tile generation.
• I'm unsatisfied with the current argument flags, and how they're setup, I'm looking to change things, and would appreciate some feedback. I'm hoping that the new argument structure keeps the power of the script, and leaves it flexible enough to add new platforms and options going forward.

I want to make sure that the new structure of arguments doesn't ruin everyone's workflow, just because it suits mine.

Proposal for MSIE

In recent weeks I've noticed more and more requests to browserconfig.xml creeping up in our access logs, and would like to add support for MSIE into the resizer. An icon should be resized into all the arguments provided by MSIE to make Windows 8 / Windows Phone 7&8 tiles for IE10 and 11.

More about this here: http://msdn.microsoft.com/en-us/library/ie/dn320426(v=vs.85).aspx

New argument structure

Usually my workflow for icon generation comes after the designers have decided that the icon works at anything from 50x50 to 1024x1024. I receive the 1024x1024 and just want to run it through the script and have it spit everything out for me. Regardless of Android, or iOS.

In the following examples any instance of --file can be replaced with --folder. So either an individual file, or an entire folder would be processed.

I'm unhappy with the interaction of the -i and -a flags and their interaction with --app-icon and --pngconv. I don't think I thought those through enough when I created them, and now it's a bit messy.

Right now...

• ... to to format a JPG to a PNG, you have to specify -a or -i which is absurd, as the PNG conversion can be done regardless of iOS or Android resizing logic.
• ... to generate iOS app icons, you have to specify -i --app-icon --file which are too many arguments for a simple app icon resize.
• ... the -prod argument is very android specific.

New argument structure

Platform agnostic flags

• PNG Convert: This would include --pngconv. Any file specified with --file can be converted to PNG, regardless of platform. The new way to convert an image to PNG, would be: --pngconv --file /my-jpg.jpg
• New: Resize any image to any size: --resize wxh. A new flag that would you resize any file specified with --file to the provided width x height dimensions. The way to resize any image would be: --resize 300x300 --file /my_1024x1024.png.

iOS flags

• All iOS related arguments would be prefixed with --ios for clarity.
• To resize an @2x image it would now be --ios --file [email protected] which would output image.png into the same directory.
• To generate all app icons it would now be --ios-app-icon --file app_icon_1024x1024.png which would output all app icons, spotlight, settings, toolbar, etc. sizes as it currently does into the same directory.
• New: Generate web clip icons --ios-webclip-icons --file app_icon_1024x1024.png which would output web clip icons for iOS7 and above. Useful for web developers allowing users to shortcut their sites with nice icons.

Android flags

• All Android related arguments would be prefixed with --android for clarity.
• Creating application icons should be done in a similar way to iOS, where we can point the script at any large file, and have it spit out any density. I propose the sizes be calculated from the mdpi baseline of 48x48 dp. Thus --android-app-icon --file app_icon_1024x1024.png would result in mdpi of 48x48, hdpi of 72x72, xhdpi of 96x96, etc. As all scales going up (xxhdpi, xxxhdpi, xxxxhdpi) are just multiples of the baseline, this can easily future proof for any more higher densities added into the SDK.
• Resizing Android images as before would now be --android --file drawable-xxxxhdpi/image.png and it would resize into all scales, unless excluded with --exclude-scale.
• The --prod flag would be replaced with --android-prod, but function the same way.

MSIE flags

• New: Completely new resizing class that could accept a default 1024x1024 icon, and resize it to the square icons defined in the MSIE Browser Config document (http://msdn.microsoft.com/en-us/library/ie/dn320426(v=vs.85).aspx). This would be run with --ms-browserconfig --file app_icon_1024x1024.png and have it return the square options defined in the document. This would not handle the 310x150 case in its first iteration. Note: This is intended for browsers. I do not know enough about Windows 8 development to know all the required icon sizes for desktop / phone development. If anyone has any insights, feel free to share in a comment.

Thanks in advance for any feedback given, and hope this will improve the script going forward. Thanks to everyone who has contributed, and uses the script.

I'm getting

Traceback (most recent call last):
File "/usr/bin/android-res-resize.py", line 15, in
import Image
ImportError: No module named Image

could someone help me?

AC

• Given a 1024x1024 image, allow specification that this image should be 44x44 @1x, and have script appropriately size @2x and @3x images

After this PR #14 the default now appears to be xxxhdpi, but this isn't mentioned anywhere in the README. I had been labouring under the assumption that the default was xxhdpi and ended up shipping an app with teeny tiny icons 😞

'print' is no longer an expression but a function. Consequently, print statements now require parenthesis.

print "hello world"
becomes
print("hello world")

Using --resize have the ability to resize a specific --file or --folder. The argument for --resize should be a widthXheight format, like 200x300.

Ability to exclude certain scales from being processed.
Something like --exclude-scale ldpi

In the (unlikely) event of wanting to resize a NinePatch image, the transparency of the resized images is not retained leading to invalid NinePatch images.

Arguments:

• --pngconv --file ~/path/to/file.jpg
• --pngconv --folder ~/path/to/folder/

Convert accepted file extensions (right now JPG) and convert them to PNG. This will rename a file as well. image.jpg will turn into image.png.

When using --prod option it's assumed the script is in the android project. Would it make more sense to have it as a path relative to current working directory?

~/code/myproject/ $ ~/tools/android-res-resize.py --prod will fail, as ~/tools/ does not have a res/ directory.

I am assuming that --prod could be run from anywhere (easier if it's in $PATH) but would run --prod from current working directory.

~/code/myproject/ $ ~/tools/android-res-resize.py --prod would work as ~/code/myproject/ has res/ folder in it.

What's expected behaviour?

Make script executable by adding default python shebang.