Allow the user to supply pixel-perfect icons at both 1x and 2x resolutions

[joerick]

Currently when the --retina flag is used, the input images are assumed to be the 2x version and the 1x version is generated by scaling. I'd like the option to provide two resolutions of each icon and have the 1x version used instead of a scaled version.

Apple's convention for this in UIKit and AppKit are to have filename.png and [email protected] for each asset. I see glue has adopted this in it's output, perhaps we could do the same for input files, so for a filenames like:

nav-arrow-left_hover.png
[email protected]
nav-arrow-left.png
[email protected]
nav-arrow-right_hover.png
[email protected]
nav-arrow-right.png
[email protected]

I'd like to supply a pull-request, but I'd like the maintainer's/community's opinion on a couple questions-

• Do we roll this into the --retina and --ratios= commands, or make something separate?

Advantages of rolling into the existing commands would be that the user could supply pixel-perfect 1x versions for some icons and accept the scaled versions for others. Only problem with that is the abiguity between the fact that normally a filename without '@2x' goes to the '@2x' spritesheet, but in this case a filename with '@2x' goes to the standard resolution spritesheet (or we could adopt a convention of '@1x' instead?)

• Order of the suffixes, i.e. [email protected] or nav-arrow-left@2x_hover.png. I think I'm in favor of [email protected].

[jorgebastida]

I really like the idea @joerick
About your questions, I think we should introduce this feature as part of the --retina option in order to allow people to supply some pixel-perfect assets (if they need them) not adding more complexity.

About the abiguity... yes it is tricky, but the @1x options sounds quite clever for me.
Right now glue creates the @2x sprite and then scale it down to the @1x version. We should change this implementation a little bit.

• Ignore images that contains ratio information @\d+(.\d+)?x
• Make the image format not create one image and then scale it down for each ratio. We need to create sprites one by one. If there is no any source image available for this specific ration (let's say [email protected]) we'll get the original car.png and scale it down by a 50% and include it within the sprite. If it is available... use it.

As result the image generation would be slightly slower... but it should not be a problem.

About the order, I think we should keep this @2x suffix as the last one, yes.

I would really like to merge a pull request with these changes :D

[J22Melody]

I also run into this issue.

The --retina flag is nice but sometimes I really want a more pixel-perfect 1x icon.

I agree that Allow the user to supply 1x icon is the best solution and has the pull request or update been made yet ? @joerick

If not, I wanna have a try, though I'm not quite familiar with python... maybe some instructions would help me :D

Or some other way to improve the quality of @1x icons generated by glue ?

[msikma]

I think this would be great. I really need this functionality to make the whole thing integrate nicely into my our current setup. I'd recommend searching for [email protected] files and then making an attempt to match the file.png equivalent, rather than mandating @1x which is not standard.

It's also worth adding an option to change the infix to _2x instead of @2x. Apple changed their minds around 2013 about the @ and now advise the use of an underscore instead. This is the setup we're currently using at our company.

Finally, even though we're talking about @2x in this thread, indeed retina isn't just a 2.0 pixel ratio so the regex that @jorgebastida posted is the most future-proof method.

[berarma]

The automatic image scaling is a great feature for faster development but when images should be pixel perfect (specially important in the smaller ones) the only way is to provide our own images.

Rendering small images directly from vector graphics works better than scaling down. And another benefit is that the resulting files are also usually smaller since the dithering produced by scaling images down doesn't compress as much as the pixel perfect versions.

So I agree to:

• be able to provide images instead of always relying on scaling.
• use suffixes, so always at the end of the file name.
• configurable separator character for suffixes would be very nice.
• support for any ratios, fractional ratios too, 1.5 is common and more to come.

[berarma]

It's worth mentioning this would fix the following issues: #82, #121, #159. In cases where the scaling feature is preferred at least it would provide an easy workaround.

We're talking about fixing also this (I think they're dups): #153, #202. Theres a PR already: #204.