Add layers blending effects in SVG for photoshop compatibility

[Emasoft]

Export from Photoshop in SVG is currently very difficult because of the lack of layers blendings effects in the SVG format.

SVG is not able to specify all mix-blend mode effects of Photoshop layers because it is limited to the color composition. All other layer blending effects in the image are now lost when saving in SVG format. I'm referring to the following in particular:

Drop Shadow Adds a shadow that falls behind the contents on the layer.

Inner Shadow Adds a shadow that falls just inside the edges of the layer’s content, giving the layer a recessed appearance.

Outer Glow and Inner Glow Add glows that emanate from the outside or inside edges of the layer’s content.

Bevel and Emboss Add various combinations of highlights and shadows to a layer.

Satin Applies interior shading that creates a satiny finish.

Gradient and Pattern Overlay Mask Blend the layer’s content using a patterned or gradient overlay mask.

Stroke Outlines the object on the current layer using color, a gradient, or a pattern.

Alpha Channel Mask Image Blend the layer’s content using a custom alpha channel mask image.

Those filters are all already present in the SVG specifications, but only as graphic elements filters. All we need is to be able to also apply those to edges of the layer’s content as blending options. In this way it would be possible to preserve layers effects when saving in SVG from Photoshop and other painting applications.

[tabatkins]

I think all of these are possible today with SVG filters. They can be applied to <g> elements as well, which are the analog of "layers", as they group graphics elements together.

[Emasoft]

No, they are not. You are not a graphician used to Photoshop, I suppose. Let me explain: you need to apply them to the EDGES of the layer's content. Not to all elements of a layer. Also groups are very different from layers. Groups have no z order. I can group a bunch of boxes, as a single object, for example a desk, but I still need to have different pieces of the desk on different layers (i.e. floor, legs, support, paper, books, etc.). I need to treat layers differently because of their ordering, and I need a quick way to select all elements on top, all those at the layer below, and so on until I reach the bottom layer. This is the only way I can be sure to drop shadows on the object behinds, and not on the objects above. Layers are just an integer z value attribute that each svg element should have. And all blending effects should only be cast on elements of the layers below, not on the layers above. And not as single elements, but as a boolean merge of all elements shapes, forming the layer's content EDGE. This is how layers works in all graphic tools like Photoshop. And currently there is no way to do this in SVG.

[nikosandronikos]

If you need to 'group' objects as in photoshop you can use the feComposite filter. Then apply the drop shadow to the result of the composite.

[Emasoft]

You cannot use the feComposite filter, because it will rasterize the vector elements. Then you have no reason to save in SVG format. If I create a vector element it is because I need it to be vector format. I can only allow the shadows to be raster, but not the elements in the layer casting the shadows.

[BigBadaboom]

The rasterization only happens as the elements are rendered, so it will be done at whatever resolution the output device is. So I am not clear on your objection. I know there are some effects that are not possible with the set of SVG filter primitives available, but can you provide an example of an effect that you care about, that you don't think is possible?

[Emasoft]

@BigBadaboom The point is not the rasterization per se (that by itself still force the objects to be rendered at a lower resolution once merged with the feComposite in a single shape, due to the fact that the raster buffer is not updated when the page is zoomed on a mobile browser, for example, but it is generated once at the page setup. So when you pinch zoom the vector elements of an SVG are kept sharp, but the rasterized elements becomes pixellated... this is another issue of the svg spec that should be fixed). The point is that the SVG format lacks a layers specification system. There is only the group system, but it's insufficient. This is why for example Inkscape was forced to create its own non standard layer system, that creates compatibility problems when you load Inkscape SVG in other programs like Illustrator or Affine Designer, and you loose all the layers attributes and definitions. To be able to support layers and preserve all informations about them and their compositing/blending/masking effects when exporting SVG from softwares like Photoshop, SVG must introduce a layer index. All you need is to add a layer attribute to every object, with an integer value.

svgelement name="house" layer="1" ... svgelement name="tree" layer="2" ... svgelement name="dog" layer="1" ... svgelement name="forest" layer="3" ... ... When the layer attribute is missing, it shall just assign the object to layer 1, so it will be perfectly backward compatible with existing SVG files.

@nikosandronikos You cannot use groups as layers. They are two very different things, and they should be treated differently. Layers are about z-ordering. Groups are about entities of the same set that can span from front to back, regardless of the z index. A group of "cars" on a road can have very different z indexes for each car. And you cannot just create subgroups, because cars with the same z coordinate must belong to the the same layer and at the same time they can be assigned to two different groups. Here is an illustrated explanation:

[jarek-foksa]

@Emasoft Which vector graphics editors implement layers according to that graph? I don't think Inkscape allows you to have two objects that belong to the same group while simultaneously being in different layers. I was also unable to figure out how to do that in Affinity Designer.

[Emasoft]

@jarek-foksa That is exactly the point. NOT being able to group objects across layers has been a major gripe for years, and people are resorting to tricks to obtain the same result (see for example the classic save-selection trick in Illustrator: http://www.designgeek.com/group-across-layers-illustrator-0 ). But for SVG is even MORE important. Groups are used in SVG for animations. For example the image of a car needs to contain the "car" group with all elements of the car. To be animated and moved I need the group "car" so I can refer to it when animating it. I'm not going to animate (in js or smil) every single piece, because it will bloat the code. But at the same time the car should be composed by objects on different layers (seats, passengers, doors, handles, wheels, windows, windscreens, wipers, etc.), each layer with its own blending effects attributes. So the need for a different management of groups and layers is even more paramount in SVG. The only thing stopping Inkscape to implement groups across layers, is the lack of this feature in the SVG specifications. And it is very easy to add: you don't need to bother with groups as they work now in SVG. All you need is to add a simple "layer=n" attribute to every svg element (not groups), and you solved both problems.

[BigBadaboom]

Okay, sounds like it is a wishlist feature that no editors support. You are wanting to use layers in a bit of an unusual way. Layers were intended for use on a more macro scale. Eg. background, mid-ground, foreground, etc. If you want to edit your car, why not just split the group temporarily, or use Illustrator's "isolation mode" feature?

[Emasoft]

@BigBadaboom You seem to not understand the point. Such feature is instrumental to allow software like Photoshop (and also Inkscape, Affinity Designer, Illustrator, Sketch, etc) to preserve layers and blending effects when saving in SVG. SVG needs a layer management independent from groups. Is this clear or not? Not providing layers in SVG as a separate domain from groups you are crippling the SVG format for no reasons, and limiting its usage. Inkscape resorted to add non standard proprietary metadata, Photoshop just merge all objects in one big layer, javascript coders are using additional code to emulate it.. what else do you need to understand the importance of this feature?

[BigBadaboom]

what else do you need to understand the importance of this feature?

An example

[Emasoft]

@BigBadaboom I just made an example in the sketch image above. That is an example of a vector image that I need and that SVG cannot provide. People have been asking about this for years. You just have to add a simple integer value. Why do you keep making life harder for both artists and developers not adding layers in SVG?

[progers]

@Emasoft, how should the following render in your proposal (https://output.jsbin.com/desoci)?

<g filter="url(#dropshadow)">
  <rect x="100" y="100" width="100" height="100" fill="red" layer="1"/>
  <rect x="150" y="160" width="100" height="100" fill="blue" layer="3"/>
</g>
<rect x="125" y="125" width="100" height="100" fill="green" layer="2"/>

[BigBadaboom]

@Emasoft I am talking about an example showing a file that can be represented in some editor, but can't be reproduced as SVG due to lack of support for "layer blending effects".

[Emasoft]

@progers Simple: objects on different layers should be affected by group effects separatedly.

In other words: it will be rendered like if was written in the following order, with the dropshadow effect applied separatedly to the two groups with the same name. But those groups would still be the same group, so any effect or animation applied to GROUP_A will be applied to both the red rectangle AND the blue rectangle. If I translate the GROUP_A, both red and blu rectangles are translated. Yet they are rendered in an order dependent by their layer.

<g name="GROUP_A" filter="url(#dropshadow)">    
  <rect x="100" y="100" width="100" height="100" fill="red" layer="1"/>   
</g>   
<rect x="125" y="125" width="100" height="100" fill="green" layer="2"/>  
<g name="GROUP_A" >    
   <rect x="150" y="160" width="100" height="100" fill="blue" layer="3"/>   
</g>

In this way I can change the layer of an object, without affecting the group to which it belongs.

NOTE: this example is not about layers blending effects. Those are applied to layers, with a special syntax, adding lines like this to the above code:

<layer_blending_effect  layer="1"  filter="url(#dropshadow)" />
<layer_blending_effect  layer="2"  filter="url(#glow)" color_blending="multiply" />

In this way all elements belonging to a certain layer are rendered and blended according to their specific effects, color method, etc.

[progers]

@Emasoft, that seems to be the same as z-index (https://svgwg.org/svg2-draft/single-page.html#render-ZIndexProperty). Can you talk about how layer and z-index would differ?

[AmeliaBR]

@Emasoft

You introduced this thread by suggesting that it was about features supported in Photoshop that are not in SVG, making exporting difficult. We know that there are still some missing features, but there is definitely support for minimizing those differences. Blending modes address many of Photoshop's layer effects, filters and backdrop-filters address others. Compositing effects currently require masking or clip-paths, which may mean thinking about the structure of the graphic differently, and may require you to <use> a layer group inside the mask or clipPath element.

None of this requires a new "layer" element. Since SVG groups can be nested, and can have any of these effects applied, an SVG group can be used to represent any content layer. Graphics software can (and do) use custom-namespaced attributes to distinguish between layer groups (which have these effects available in the GUI) and organizational groups. Photoshop effects or adjustment layers (which modify other layers but don't add their own content) would need to be converted to clip-paths, masks, or filters, or some combination of a solid color rect and blend-modes.

The proposal you suggest above, of having groups that span multiple layers, is something quite different. As far as I know, this is not possible in Photoshop or any of the main vector graphics software. These all use a strict tree structure to organize components. Groups of elements are always in the same layer.

However, it is possible to create this sort of effect on the web, with restrictions, using CSS z-index or class-based style groups. Although z-index is not supported in web browsers for SVG content yet, it is in the SVG 2 spec & will hopefully be implemented soon!

Using z-index, you can define a layer stack for elements that persists across different groups. This seems to be exactly what you want with the layer attribute in the sample code. The only restriction is that graphical effects such as filters or clip-paths flatten all the layering of their child content. If you want to apply graphical effects without flattening the z-index layers, you would need to add the effects individually to the same elements that have the z-index property (or to their child content).

In other words, you could use the following code:

<g>
  <rect x="100" y="100" width="100" height="100" fill="red" 
           z-index="1" filter="url(#dropshadow)"/>
  <rect x="150" y="160" width="100" height="100" fill="blue"
           z-index="3" filter="url(#dropshadow)"/>
</g>
<rect x="125" y="125" width="100" height="100" fill="green" 
           z-index="2"/>

The element without the shadow would be drawn in-between the two elements with the shadow (once z-index for SVG is supported in browsers!). Note, however, that the drop-shadow effect would be slightly different, since it is applied to the two rectangles individually, not to the combined shape.

Under the SVG 2 specification, you would still be able to apply a 2-dimensional transformation to the <g> element, and have it apply to both elements, without flattening the grouped layers together. This is different from CSS layout, which treats 2D transformations as a graphical effect.

Another way to maintain "groups" of elements, e.g. for animated transforms, across different layers, even when those layers have graphical effects on them, is to use CSS classes. The different elements are not grouped by a <g> in the markup, but instead by the shared class. You could then apply the animation or other shared features of the "group" by using CSS rules to apply them to all elements in that class. (This is one of the reasons why CSS animations are gaining popularity over SMIL: you can apply the same animation to independent elements without repeating the code.)

Again, this may require thinking about the structure of your document differently. If you have a practical example of something that works in Photoshop, Illustrator, or other software, and are not sure how to export it as SVG, we could help point you in the right direction. As I mentioned, some features are not well implemented yet, and some specifications are still in development, but between CSS and SVG I think the intention is to eventually capture all the graphical effects that are used by common 2D layout and vector graphics software.

[Emasoft]

@progers You could have linked that before! Z-index is the same thing I'm asking since the beginning of this thread! LOL

But there are some small differences:

• Z-index does not allow to label a layer. Names are important because from code or from an editor, I should be able to apply a change to layers called "mountain-road" or "cars-on-the-road". Using numbers is not enough. Numbers and ordering can change, but the layer name must not.
• Z-Index is not an entity explicitly provided with attributes, like a layer, but just an attribute. It should be an entity. So I can set hide/show attrbutes, apply layers blending effects, and so on. Something like:

<Z-INDEX position="4" name="mountains-layer" visible="true" blendingfilter="url(#dropshadow)"  color_blending="multiply" mask="url(#someobject)" />

• Z-index does not include the attribute for 2D offset. Layers offsets are very important, especially for animations (i.e. Parallax scrolling of background layer behind foreground layers). Two attributes, xoffset and yoffset, should be present and animatable:

<Z-INDEX position="4" name="mountains-layer" visible="true" xoffset="10,708" yoffset="-40,055" />

I think that if those small changes will be made to the z-index, it could become a true layering system for SVG.

[Emasoft]

@AmeliaBR Thanks for the explanation. As I said to Philip, I was asking exactly for the z-index feature. I didn't knew that it was already added to the SVG2 specs. I think that adding the small changes I listed above to the z-index, we can came up with a working layering system for SVG. But as you said, there are some other issues. Let's consider those you mentioned one at time:

• Issue 1 - graphical effects such as filters or clip-paths flatten all the layering of their child content. If you want to apply graphical effects without flattening the z-index layers, you would need to add the effects individually to the same elements that have the z-index property (or to their child content).
• Answer to Issue 1 : This can be solved in the way I showed above, where I split the same group in two groups with the same name. That can be an internal rapresentation derived from the SVG file with layers. When a group is split according to the layers, the same effect is applied to all derived groups. All derived groups have elements and sub-elements with the same layer or z-index. Once you have made this split, you just have to render the effects or the masks on each derived group separatedly and according the z-order. And that will solve the issue.
• Issue 2 : CSS classes are used to "group" elements, so why using layers?
• Answer to Issue 2: Because SVG should not be dependent on web standard. As I explained in this thread:
  https://github.com/w3c/svgwg/issues/63
  Many people and companies trusted SVG as a standard graphic format, and used it in many fields outside the web and the browser. My company is doing so, and many other are working with SVG as their primary asset for mobile, animations, video, ebooks, videogames graphics, office suites, 3D cad, etc. No one of those fields can use CSS, because CSS is designed to style web pages with tons of features useless in those ones. CSS is too bloated to be reimplemented in an efficient and useful way outside the browser world. SVG is now already self sufficient and it allows to create graphics and animations without having to implement a mini browser every time you need to display an Svg icon inside an app. SMIL is also much better than CSS on many things (see again the thread linked above for the discusion), and if some small issue still exist it can be easily fixed in the next specifications. Throwing SMIL out of the window to embrace CSS is like killing all people using SVG outside the web. Companies like the one I work for would feel betrayed, and surely no one would take SVG seriously anymore. So please: avoid making SVG dependent on web standards or external style sheets. SVG is used by graphicians and artist all over the world, that create beautiful animations in pure SVG+SMIL without writing any code, but just saving from some graphic application like those I mentioned in the other thread. SVG is the lingua franca of vector graphic and animation. It is the lingua franca of the graphic world, the only one that you can use everywhere in all kind of fields, from mobile apps to architecture visualization. Take the best of CSS and integrate it in SMIL, if you want, but keep SVG free and independent. Doing so will help the web too, because web graphicians are not coders, and cannot be asked to create beautiful animations without animation tools like Adobe Animate CC or the one my company is developing. SMIL is the future of the SVG and of the web. Because without SMIL, you cannot have graphicians creating animations. No artists will ever use CSS, and SVG animations will be relegated to small javascript tricks, and will never take off. Today an artist can take Adobe Animate CC, create an entire cartoon, and save it in SVG+SMIL thanks to the flash2svg plugin. No CSS or javascript or HTML needed. Just a graphic file. Like the SVG that the original creators intended.

[Emasoft]

I forgot to mention another important attribute that the z-index needs to be truly capable of supporting layers: transparency.

So, recapitulating, the features that I ask to be added to the z-index are the following:

• Making it an entity and not an attribute:

<z-index ... position="2" ... />

• Provide it with an unique name or id attribute:

<z-index ... name="background layer" position="2" ... />

• Provide it with a "visible" attribute

<z-index ... visible="false" position="2" ... />

• Provide it with a blending_filter attribute

<Z-INDEX ... blending_filter="url(#dropshadow)" ... />

• Provide it with a color_blending_method attribute:

<Z-INDEX ... color_blending_method="multiply"  ... />

• Provide it with a layer_mask attribute:

<Z-INDEX ... mask="url(#some_element)"  ... />

• Provide it with an xoffset, and yoffset animatable attributes:

<Z-INDEX ... xoffset="10,708" yoffset="-40,055"  ... />

• Provide it with an height_scale, and width_scale animatable attributes:

<Z-INDEX ... height_scale="0,708" width_scale="2,055"  ... />

• Provide it with a transparency animatable attribute:

<Z-INDEX ... transparency="25%"  ... />

So each svg z-index layer should be first declared like this:

<Z-INDEX position="4" name="mountains-layer" visible="true" xoffset="10,708" yoffset="-40,055"  height_scale="0,708" width_scale="2,055" transparency="25%" color_blending_method="multiply" mask="url(#some_element)" />

And then used in any svg element (not groups!) like this:

<anysvgelementnotgroup ...  z-index="4" ... >
 ...
</anysvgelementnotgroup>

I also suppose that the "position" value can be automatically inferred by the order of the z-index declarations in the svg document, so you can avoid to explicitly add it as an attribute. And of course if no z-index entity is declared, a default z-index entity with position="1" should be used for all objects to ensure backward compatibility.

If those small changes will be made to the z-index, it could become a true layering system for SVG, and will allow artists to use modern tools like Photoshop, Affine Designer, Illustrator, etc. to export and import in SVG without losing informations about the layering.

[Emasoft]

We also need this in SVG 2, can we make in time? SVG 2 should NOT be another format without layers management, or SVG will be out of the graphic world for other 4 years! We need to act before it's too late!

[jarek-foksa]

@Emasoft I doubt anybody here will like the syntax you have proposed. To be honest it looks awful, you have pretty much reinvented the <g> tag, but with a lot of clutter that is inconsistent with well established SVG and HTML conventions.

I still can't understand what is the rationale behind all this other than making it easy for Photoshop to export its files without resorting to ugly hacks.

As I said earlier, both Inkscape and Affinity Designer don't handle layers as per your proposal. Also, both tools don't support applying filters directly to the layer rather than to the layer contents. In my opinion adding this feature will harm SVG adoption by making the format even more complicated and harder to support.

As far as I'm concerned, I feel comfortable with the top-level-groups-as-layers approach:

<g id="background-layer" style="visibility: hidden; opacity: 0.25;">
  <desc>Background Layer</desc>
</g>

[Emasoft]

@jarek-foksa You seem to have been missed part of the discussion. The feature I'm asking is already been added to the specs, and it is called z-index: https://svgwg.org/svg2-draft/single-page.html#render-ZIndexProperty All I ask is to add some attributes to it, to make it working for artists. I worked as a graphic developer for many years, and I can assure you that the most common feature asked by graphic artists working with SVG is this: true layers.

[jarek-foksa]

@Emasoft z-index is a CSS property. You are proposing to introduce a new element with the same name as the mentioned CSS property which looks confusing to me.

You are also proposing to add attributes that don't follow naming conventions used by SVG and CSS (name vs title/desc, visible vs visibility, blending_filter vsfilter, color_blending_method vs mix-blend-mode, xoffset/yoffset/width_scale/height_scale vs transform,transparency vs opacity).

I have been working as frontend web developer and web designer for several years as well. I was using Inkscape to design mockups and then I was coding them into Drupal themes. I fail to understand how the features you are proposing would be useful to me.

[Emasoft]

@jarek-foksa Sorry, I was not using the correct terms because I wanted to be expressive. But the right terminology is the one you listed, I will rewrite my post using the correct terms. About the layering: I don't know a single professional software exporting in SVG that doesn't support layers: Illustrator, Photoshop, Affine Designer, Inkscape, Adobe Animate CC, Anime Studio, CACANi, etc. I use them all, and the problem is aleays the same: if you need to animate something you need to edit the file and change the groupd, sistematically breaking the layers made with the fake groups trick. You do not have control on groups and layers separatedly if you use groups for layers. Thanks to the new specs in SVG 2 we will finally have a true z-index based layering independent from groups. So all we need now is just to make the z-index an entity add those few attributes. Now I will make a post with the correct names.

[Emasoft]

UPDATED SPECS for z-index (see: https://svgwg.org/svg2-draft/single-page.html#render-ZIndexProperty )

So, recapitulating, the features that I ask to be added to the z-index are the following:

• Making it an entity and not an attribute:

<z-index ... position="2" ... />

• Provide it with an unique id and title attribute:

<z-index ... id="background-layer1" title="far mountains" position="2" ... />

• Provide it with a "visibility" attribute

<z-index ... visibility="false" position="2" ... />

• Provide it with a filter attribute

<Z-INDEX ... filter="url(#dropshadow)" ... />

• Provide it with a mix-blend-mode attribute:

<Z-INDEX ... mix-blend-mode="multiply"  ... />

• Provide it with a layer mask and a clip-path attributes:

<Z-INDEX ... mask="url(#some_element)" clip-path="url(#some_element)" ... />

• Provide it with an transform attribute:

<Z-INDEX ... transform="translate(140 105) rotate(60 140 105 ) skewX(60) skewY(30) scale(-140 -105 300 150)"  ... />

• Provide it with a opacity animatable attribute:

<Z-INDEX ... opacity="25%"  ... />

USAGE

So each svg z-index layer should be first declared like this:

<Z-INDEX position="4" id="mountains-layer" title="Mountains in background" visibility="true" transform="translate(140 105) rotate(60 140 105 ) skewX(60) skewY(30) scale(-140 -105 300 150)"  opacity="25%" mix-blend-mode="multiply" mask="url(#some_element)" clip-path="url(#some_element)"  />

And then used in any svg element (not groups!) like this:

<anysvgelementnotgroup ...  z-index="4" ... >
 ...
</anysvgelementnotgroup>

The "position" value can be automatically inferred by the order of the z-index declarations in the svg document, so you can avoid to explicitly add it as an attribute. And of course if no z-index entity is declared, a default z-index entity with position="1" should be used for all objects to ensure backward compatibility.

[AmeliaBR]

Hi @Emasoft,

The existing z-index property cannot be used as you'd like.

The standard accepted way for converting layers to SVG is to create them as <g> element, with an extra attribute that tells the graphics editor to treat it as a layer. This <g custom:isLayer="true"> element can have:

• a unique id attribute
• a title, as the content of a direct child <title> element or as an aria-label attribute
• a visibility="hidden" option, as a presentation attribute or CSS style property
• filter, mix-blend-mode, clip-path, mask, transform, and opacity options, as presentation attributes or CSS style properties (for transform only, support is currently wider as an attribute), and in future backdrop-filter

In the future, the layer will also be able to have z-index property, so that that you do not have to re-order the code in order to re-order the layers. For now, you need to list the graphics layers in the code in the same order you want them to be layered, from bottom to top.

The only thing that you cannot do which you want is to have a non-layer "group" which is partly in one layer and partly in another. I have already suggested that you could use a CSS class to treat these elements as a group for the purposes of style effects, transformations, or animations, without them having to be a group in the markup.

The proposal you have outlined for a <layer> or <z-index> element is essentially a CSS class defined with XML. I encourage you to look into using CSS notation for this. CSS can be defined inside the main .svg file, in which case you still have a single image file that behaves as normal. If you decide to use a class instead of a <g> to represent your layer, you can add a <metadata> element to your SVG code to define the id and title from the graphics editor.

Something like:

<style>
  .layer-2 {
    z-index: 2;
    visibility: hidden;
    filter: url(#x);
    mix-blend-mode: multiply;
    /* and so on */
  }
</style>
<metadata id="background-layer1" custom:layer="2" custom:layer-title="far mountains" />

<path class="layer-2" d="..."/>
<text class="layer-2">...</text>

Again, I'm not sure whether this is worth the hassle. All existing graphics tools (Illustrator, Inkscape, etc.) export layers to SVG using groups, like:

<g custom:isLayer="true"  id="background-layer1"
   style="z-index: 2;
          visibility: hidden;
          filter: url(#x);
          mix-blend-mode: multiply">
  <title>far mountains</title> 
  <path d="..."/>
  <text>...</text>
</g>

I therefore don't think there is any viable new feature in this proposal, and will be marking this as closed.

I strongly encourage you to tell browsers that z-index is important to you, so that layer ordering can be dynamically changed without re-writing the code or changing the natural grouping. But z-index is a separate concept from layer grouping and graphical effects.

[Emasoft]

@AmeliaBR All this methods that you are suggesting are still a NON STANDARD way to define a Layer. You are still depriving artist from the possibility to export an svg file with layers from Photoshop and import it in Inkscape, reproducing all the exact layers and blending attributes. You don't seem to understand the graphicians needs. If you don't add this to the SVG standard, you are just deliberately depriving all svg artists out there of the possibility to have a standard layer system in svg, compatible and independent from the various applications you are working with. The only way to be sure that when I save an svg image with layers in Photoshop or Illustrator, I can then import it in Inkscape or Affinity, or viceversa, without loosing all layers is to have a standard layer spec in the SVG. My company is developing such an exporter, what format should I use? The Inkscape one? The Illustrator one? If there is no standard, there is no way for developers to coordinate by themselves on a single format for layers. This is what standards are for. Is this so hard to understand? The svgWG must hate layers very much.

[liamquin]

On Sun, 2016-03-13 at 14:00 -0700, Emasoft wrote:

[...] If you don't add this to the SVG standard, you are just deliberately depriving all svg artists out there of the possibility to have a standard layer system in svg, compatible and independent from the various applications you are working with.

A possibly way forward here might be to make a W3C Community Group, e.g. Creative SVG Interchange, and come up with a list of extension attributes that can be used to manage layers interoperably; this would then become a Community Group Report, and could also be taken as input to the SVG Working Group.

Just a suggestion..

Liam

Liam R. E. Quin liam@w3.org The World Wide Web Consortium (W3C) The barefoot typographer

[Emasoft]

@liamquin Thanks for the support. But it is already hard to make vendors to support main SVG features. Trying to make them to support an "extension" attribute would be just wishful thinking.

I really do not understand why it is so difficult to add the definition of layers to the SVG specs. The argument you are making, that layers cannot be introduced because they are just a special case of groups, doesn't make any sense. It is like saying: we cannot introduce RECTs, because they are just a special case of a closed polyline! And what good are polylines after all? All you need is a segment! And so on.. You don't evaluate features like this. All features are ABSTRACTIONS. Because abstractions are needed to make things more usable for humans. Otherwise we can all go back to code in binary code then.. what good is a programming language or a compiler? We already have bits!

[AmeliaBR]

I hadn't been thinking about the importance of interoperability between authoring tools.

Illustrator, Inkscape, many others all already support layers as <g>. But you're right, @Emasoft, they don't currently support them in an interchangeable way. They use custom namespaced attributes.

While it's true that the distinction between group and layer has no effect when displaying content, it is important for authoring tools that do use layers in the editor. Improved interoperability of all SVG-related software is something we should encourage.

So maybe all that is needed is to introduce a standard attribute on the <g> element, that describes it as a layer to any software that supports the concept of layers. Other attributes might describe important metadata about the layer. Other software, including browsers, would still use it simply as an ordinary group.

Are you able to do some comparison of the existing SVG formats created by these programs? Do they have a consistent concept of layers between them, or are there important differences in the way layers behave within the software? What attributes in what namespaces are used to define the layer and preserve its metadata?

If there is a consistent conceptual set of metadata that multiple programs use for layers, but they currently use custom-namespaced attributes, it would make sense to replace these with standard, interoperable attributes.

For example, Inkscape uses inkscape:groupmode="layer" and inkscape:label="label given by author". What are the equivalent properties for other SVG-creation tools?

I do agree with @liamquin, however, that this is best served in a separate extension spec. Since it only applies to authoring tools, not user agents, it doesn't need to be in the main SVG spec. That's actually a good thing, though: it means that the schedule for making this happen can work at its own pace, not constrained by the publication timeline for SVG 2.

However, to make it happen we'll also need support from creators of SVG tools. At least two independent implementations are required for a W3C standard. If you can get support from Adobe and Inkscape developers, that would be a big help, but I'm sure smaller software companies have an even greater interest in interoperability.

This thread is already very long & has covered many topics. Rather than re-open it, I've created a separate issue (#68) specifically on the idea of creating an interoperable standard for layer metadata in SVG authoring tools.

[Emasoft]

@AmeliaBR I'm very happy that you changed your mind. I'll talk about this with my boss, but I think that if an NDA is signed we may use the svg animation editor that my company is currently developing (but has not yet announced). You should contact Inkscape devs and Affinity Designer devs too. I chatted with them many times and they gave me the impression of being in serch for a solution for the layer problem too.

[nikosandronikos]

I have to say @liamquin 's suggestion of a community group is a good one. This discussion really needs the tool vendors to be involved and to make a decision on what they'll support. Maybe Adobe doesn't want you opening files created in Photoshop in other tools with the same editing capabilities? ;) Maybe they do, but it'd be nice to know before spending a lot of time writing specs.

[tabatkins]

So, carrying over conversation from #68, which accidentally turned into a repeat of this one...

The <g> element in SVG represents the photoshop concept of "layers".

You are talking about some different concept which you've called "groups", where a group can contain elements from multiple layers. What, precisely, can you do with a "group"?

You've hinted that one thing is that you can transform them together. Is there anything else?

[liamquin]

On Mon, 2016-03-14 at 17:38 -0700, Tab Atkins Jr. wrote:

So, carrying over conversation from #68, which accidentally turned into a repeat of this one...

The <g> element in SVG represents the photoshop concept of "layers".

It might be more productive to think in terms of Inkscape and Illustrator layers, since PhtoShop doesn't have objects with sob- objects that could conceivably be in different layers.

In Inkscape at least, though, if you have an object A and another B in two different layers, and you group them you end up with a new object C that's all in one layer; if you ungroup object C you're back to objects A and B, but now they are both in the same layer.

The g element in SVG corresponds to Inkscape's Group concept; Inkscape also uses elements for layers, with extension attributes such as inkscape:groupmode and inkscape:label. These attributes (I think actually perhaps a sub-element for group names might be better) seem good candidates for some standardization, whether within SVG or elsewhere.

Liam

Liam R. E. Quin liam@w3.org The World Wide Web Consortium (W3C)

[BigBadaboom]

OP has still not posted a real and practical use case for this feature. It is not obvious to me why you need to have objects grouped across different layers.