Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


iOS and Android asset generation options (for discussion) #183

wants to merge 2 commits into from

5 participants



I've implemented a first take on iOS asset generation options. I'm an iOS/Android developer and plan to continue working on this and to active use it in everyday work. This pull request is meant to open the discussion about the way Adobe wants these features implemented, not for actual merging.

There's a bunch of stuff added here:

  1. Ability to add arbitrary type-checked options at the end of a component spec, like myfile.png iOS padTo=100x100. The options and their types are declared at the start of the file, see TYPES and OPTIONS.

  2. pad option that accepts a CSS-like list of dimensions and adds the specified top/right/bottom/left paddings, e.g. pad=0:0:3:0. The units are ignored for now, always assumed to be pixels.

  3. padTo option that pads the image to the specified size, e.g. padTo=64x64.

  4. padToMultipleOf option that pads the image so that it's a multiple of the specified size (this option can only be enabled via iOS option right now)

  5. iOS option that actually turns the current component into two components, for 1x and 2x assets. So image.png ios is turned into an equivalent of 50% image.png, image@2x.png padToMultipleOf=2, and pad and padTo values are also correctly scaled for the 1x asset.

I'm open to re-imagining and re-implementing these options in a way that can eventually be merged into the mainline. Until then, I'll be maintaining my fork. I realize it can be a long time, judging from other enhancement requests, and that the final syntax will probably look nothing like the current one.

I intend to add a similar option for Android resources in about a month (or maybe sooner) as well, and maybe other features based on my actual usage experience.

Known problems:

  • test coverage is minimal (just a few parsing tests)
  • pad, padTo ignore the units, always assume pixels — should either disallow units, or support any units
  • the current design is assumed to be for Retina displays (2x, aka 320 dpi); this is adequate for iOS use cases, but some Android designs may be done at 3x now or in the future; we could use current document's ppi to determine this, although that probably will be an obstacle for most users; I'm yet to see a design PSD that isn't using the default 72 ppi value

@andreyvit Awesome! Thanks for starting the discussion on this -- your PR is exactly the way to get the ball rolling.

First, I'd like to loop @timriot in to help us iterate on the syntax you propose. Once we get the spec right, then we can iterate on the implementation.

@timriot what say you?


@joelrbrandt Let's look at this for a future release. I like the pad options a lot.


@joelrbrandt, @timriot Guys, I've updated my branch on top of the latest master. I've dropped 'iOS' option because you now have the defaults system. I've converted the grammar to Peg.js, and the options now use a hashtag syntax.

E.g. for iOS, I currently use:

default #padmul(2) 100% @2x, 50%, #padmul(3) 150% @3x

Supported options:

  • #pad(t,r,b,l) — add the given amount of padding (if less than 4 numbers are specified, the behavior is like in CSS)
  • #padto(w,h,alignment) — pad to the given size (again, you can specify only 1 number); alignment is optional, it can be either L/R/C, T/B/M (M for Middle), or full names left/right/center, top/bottom/middle
  • #padmul(w,h,alignment) — pad to a multiple of the given numbers; alignment is optional here as well

Let me know what you think!


@andreyvit Wow, awesome! Great to hear from you again, as well.

@nimbupani is now helping out with product management for generator-assets, so I want to loop her in on this. We've talked in the past about creating a "community release" of generator-assets with features like this. I personally think that's the right way to feature work like this without immensely increasing our core QE burden

@nimbupani let's sync up about this sometime. Want to put something on my calendar?


Cool. As for the community release, I'm pretty sure everyone would benefit from these features being in core. (Probably not with the current syntax, though, but that's what we're talking here for.) One of the first reactions to the recent Extract Assets feature I saw online was that it's missing ability to add padding.

I'm not sure what the best syntax is. Just pad(3,2), or pad:3,2. And for padmul (arguably the most important option for mobile app designers), I actually thought about 100%*2, 150%*3 as a possible syntax. But I think clarity wins over terseness here.


I'm looking into doing something similar for an upcoming release. It's a way to set the canvas size in a way that's similar to how the image size can get explicitly set. The syntax would be [64x64] so a simple layer would be [64x64] test.png or shorthand to to [64] test.png.

Since it's canvas size it would both pad or crop depending on what it needed to do to hit that size.

If you defined the canvas size on the layer you are exporting, and defined a default layer with a scale the resulting combination would scale appropriately so something like:

default 100% scaled-at-200/@2x, 50%
[152] appicon.png

would give you

  • appicon.png (76x76)
  • scaled-at-200/appicon@2x.png (152x152)

If you defined the canvas size and the scaling in the same definition on either the layer of the defaults then the canvas size would be exact and not scale so you could also go:

default 100% [152] scaled-at-200/@2x, 50% [76] 

and get the same results as above. This would also let you do default 100% [180] iPhonePlus/@3x, 66% [120] iPhone/@2x, 84% [152] iPad/@2x, 42% [76] and hit all the iOS App Icon sizes in one pass.

Do you think this approach would meet all your needs? If there is anything I'm overlooking please let me know. Thanks!


@chrisbank It will take care of the cases where I use explicit padding, but those only happen occasionally.

However, I want iOS-friendly rounding to take place automatically. I, and all other iOS developers/designers, always want 2x assets to be exactly the double the size of 1x assets, and similarly 3x assets to be exactly triple the size of 1x. Obviously, specifying an explicit size for each layer is not even a remotely acceptable workaround.


@andreyvit Is the only missing the `ios shortcut? To me it looks like

default 100% scaled-at-200/@2x, 50%
[64] image.png

should be the same as

image.png ios

You only need to specify the defaults layer once in the document and each layer you need to add what that correct starting canvas size is.


@chrisbank I want the canvas size to be computed automatically. There may be tens or hundreds of assets per project, and I don't want to specify an explicit size for each of them. So I want the layer name to be simply “image.png”, and the default line to somehow specify that a correct rounding (or, in your terms, automatic canvas size determination) is to take place.


@chrisbank I guess you have stuff like icons in your mind when thinking about assets, that's why you think that something like [40] would be an appropriate solution. But most of the assets for a custom-designed iOS app are just various parts of UI without any predetermined customary size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Nov 20, 2014
  1. @andreyvit

    Add #pad, #padto, #padmul

    andreyvit authored
  2. @andreyvit

    Regenerate parser

    andreyvit authored
Something went wrong with that request. Please try again.