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

Ability to define global document output settings #175

Closed
timriot opened this issue Dec 10, 2013 · 10 comments

Comments

@timriot
Copy link

commented Dec 10, 2013

"There’s probably a ton of people using photoshop for iOS and Android design, and now with macbook pro retina, web designers are also using the @2x. it would be really useful to have the ability to choose a number of exports per graphic and specify the percentage. I can dream. This would also work well in the future (4k). The auto output would be better than it is currently, definitely."

Imagine defining something like “define: @2x.png auto output 50%, 200%”, with a config layer at the top of the layer stack...

Given a 400px X 400px layer with the name:

  • fred@2x.png

Expected output:

  • fred@2x.png (400px X 400px)
  • fred.png (200px X 200px)
  • fred@4x.png (800px X 800px)

Benefits of this would include getting a variety of image sized per tag would be greatly simplified and keeping the layer names themselves less cluttered.

@ghost ghost assigned joelrbrandt Dec 10, 2013

@timriot

This comment has been minimized.

Copy link
Author

commented Dec 10, 2013

@joelrbrandt I believe this is something that could be relatively straightforward to implement. If this is true, let me know and we can meet to quickly discuss syntax.

@iwehrman

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2014

Here's a proposed extension to the grammar, by way of an example: default 50% lo-res/ + 100% hi-res/@2x

The phrase starts with a new keyword, default, which indicates that the rest of this layer spec should be interpreted as a description of document-wide default settings. The remainder of the phrase is parsed as a list of components, 50% lo-res/ and 100% hi-res/@2x. Each component is similar to a file specification, but omits a file extension. The interpretation of each components is: (scale)? (subfolder/)*(suffix)?. That is:

  1. An optional scale component (e.g., 50%);
  2. An optional subfolder hierarchy (e.g., lo-res/);
  3. An optional filename suffix (e.g., @2x);

(It probably doesn't make sense to include quality here, since quality is file-type-specific.)

The rough interpretation of a default phrase like this is: for each layer asset specification, generate a version of that asset for each default component at the specified scale, in the specified subfolder and with the specified suffix. (By "suffix" I mean after the base name of the file and before the extension. So, foo.png maps to hi-res/foo@2x.png.) Note that this means that if an asset specifies multiple files then each of those files will be generated according to the defaults. So, with the given defaults, an asset specification "foo.png24 + bar.png8" would result in four files:

  1. hi-res/foo@2x.png
  2. hi-res/bar@2x.png
  3. lo-res/foo.png
  4. lo-res/bar.png

To fully specify the interpretation, we have to decide what to do if an asset specification includes local, conflicting scale and subfolder components. For each component, we can either pick the default specification if it exists, or the local specification if it exists, or some reasonable combination of the two. (As an example of combination, if there are default and local subfolder specifications, we could concatenate them to create a deeper subfolder hierarchy. And if there are default and local scales, we could multiply them.) Alternatively, we can disallow conflicts and simply ignore assets with conflicting specifications.

Disallowing conflicts is simple and easy to explain. Combining conflicting specifications is useful in some cases, but is harder to explain. Picking local specifications over the defaults is useful for expressing, well, default behavior, which has some exceptions. I can't see any merit to ignoring local asset specifications in favor of defaults. I think my initial preference is:

  1. Choose local scales over default scales;
  2. Combine subfolder conflicts, so an asset subfolder is generated within the default subfolder.

(Choosing local over default scales also dodges the awkward scenario in which both default and local scales are absolute...)

We also have to decide what to do if there are multiple default specifications. I think disallowing this is reasonable, leaving behavior unspecified; e.g., do nothing, pick one arbitrarily, etc.

Final note: I tried to design this grammar to jibe with what I imagine a layer-group and layer-comp subfolder grammar extension might look like. To understand how that would work, just get rid of the default prefix and restrict the phrase to layer groups or comps. These "default" specs then only apply to the assets either within the layer group or enabled in the layer comp.

CC: @timriot and @joelrbrandt

@iwehrman

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2014

Additional examples and grammar updates are in this branch.

@joelrbrandt

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2014

On the whole, I think this specification of the syntax sounds fantastic. A few questions:

  1. Are you imagining using exactly the same syntax for "defaults" that would be applied only within layer group (with the "defaults" tag on the group name)? If so, would those defaults completely override document-wide defaults? (I think the simplest thing to explain to users would be overriding)
  2. It still feels really weird to me to use an empty layer at the top level as a place to shove in defaults. @timriot is this really what you intend?
  3. Do defaults apply to ALL layers in the document or only to layers below the "defaults" layer? If the latter, can the user have multiple "defaults" layers? If the former, what do we do if the user has multiple "defaults" layers?
  4. I can imagine one additional default we might want to explore right now: a default base directory (that may be specified with an absolute path, or with a path relative to where the PSD is). Can you think of a way to work this into the spec?
  5. With this increasing complexity, I think it's even more important to have a good way to message errors to the user. Right now, we have "errors.txt" popping out in the case of mistakes. We need to make sure we have reasonable messaging for default errors.

Also, you definitely shouldn't take my word that the syntax is golden. @timriot is really the person to weigh in.

@iwehrman

This comment has been minimized.

Copy link
Contributor

commented Feb 20, 2014

  1. Yes, and I think the policy should be the same as the policy w.r.t. local asset specs. That is, the size overrides and the subfolders are combined. (I could also perfectly well imagine a different policy in which both components are overridden by the more-local spec.)
  2. I too would not personally want to work this way, but I gather from @timriot that there is some precedent for it.
  3. To keep it simple, I was planning to assume that defaults apply everywhere. The location of the defaults layer is irrelevant. And, as I said above, multiple defaults layers are not allowed. Could I imagine this being more complicated and powerful? Absolutely! I'm trying to keep it simple though. If I were going to go so far as to allow multiple defaults that only apply to layers at the same depth or below, then I would rather just go ahead and use the tree structure of layers and only implement this for layer groups, which I think would be much more sane and easy to understand. But if we disregard the pathological case in which someone has managed to bury a defaults layers somewhere deep inside of nested layer groups, then I don't think this is completely crazy.
  4. We could either do this with a different layer and phrase (e.g., basedir: ~/whatever/) or allow the subfolder specs to be absolute instead of requiring that they be relative. The latter should be independent of this change; if we go with the former, we should make sure the policy w.r.t. where the magic layer can exist jibes.
  5. I agree that the priority of error reporting should be raised. I also think it should be dealt with separately. If there isn't already an issue, I'll file a new one.
@joelrbrandt

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2014

There is some discussion in #159 about possible syntax for this

@iwehrman

This comment has been minimized.

Copy link
Contributor

commented Mar 25, 2014

Hey @timriot, this is approximately implemented in the iwehrman/dom branch if you'd like to kick the tires. It's still in progress though, so no rush.

Lil' demo movie here.

@timriot

This comment has been minimized.

Copy link
Author

commented Mar 26, 2014

@iwehrman Holy moly, that's awesome! (The demo movie helped quite a bit.) I'll need to play with it before I make any final statements. Either I'll stop by your desk sometime tomorrow or I assume it's just a matter of copying what's in your branch into the usual place.

@joelrbrandt

This comment has been minimized.

Copy link
Contributor

commented Mar 28, 2014

As fodder for getting this in to master sooner rather than later, there's an outside-of-github request for this feature here:

http://feedback.photoshop.com/photoshop_family/topics/allow_for_photoshop_generator_configuration

@iwehrman

This comment has been minimized.

Copy link
Contributor

commented Apr 28, 2014

Closing this as fixed for Photoshop 15.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.