[svg-native] Decide whether reusable graphical elements are needed

[jarek-foksa]

SVG 2 defines following primitives for creating reusable graphics:

• <pattern>
• <marker>
• <symbol>
• <use>
• <linearGradient href="...">
• <radialGradient href="...">.

Some of those elements are already discussed in #671 and #670, but I think the broader question that needs to be answered first is: are they adding any value when it comes to rendering performance, file read/write performance, security or interoperability?. If not, then I would get rid of them altogether just like it has been done with all the text elements.

[jarek-foksa]

One concern raised in #670 by @dirkschulze is that the file size could increase greatly if no means for graphics reuse are provided. Perhaps this could be mitigated by allowing SVG Native files to be optionally gzipiped like SVGZ?

Another concern pointed out in #671 is that supporting some of those primitives would greatly complicate the task of writing a compliant SVG Native renderer, therefore holding back the adoption of the new standard.

[jarek-foksa]

One more concern is that if those elements are supported, SVG Native would have to also support either "xlink:href" attribute (verbose and ugly) or "href" attribute (breaks backward compatibility with SVG 1.1).

[BigBadaboom]

• <pattern>
  Usage of pattern is quite high I think. Apart from its obvious use for repeating fills, there is a common use case where <pattern> is used to place images inside shape elements. I think this would be missed if it was removed.

• <marker>
  Not sure about this one. It is commonly used, but maybe not in the situations that SVG Native is intended for.

• <symbol>
  Has a very similar purpose and function as child <svg> elements, which have been removed. I'm not sure what the purpose of removing child <svg> elements was. But any argument for removing one, could equally apply to the other.

• <use>
  I think these should stay. They are commonly used and very useful for reducing file sizes.

• <linearGradient href="..."> / <radialGradient href="..."> / <pattern href="...">
  In my experience, the href attribute for these is hardly ever used. It is an obvious candidate for removal.

[jarek-foksa]

All those elements could be replaced with other more basic (and verbose) constructs. For example a <pattern> based bitmap texture fill effect could be achieved with an <image> which is clipped by a <clipPath> or has an alpha channel which imitates a clipping mask.

It looks like the main advantage of those elements is better semantics and decreased markup repetition. I'm not really sure whether this is enough to justify their inclusion in the SVG Native format, especially considering the fact that <text> is not included.

[AmeliaBR]

One thing to consider is what features are available in the native graphics libraries. If most of these libraries have a simple pattern tiling function that the renderer can call, it is a bit of a waste of bandwidth to insist that every pattern tile be encoding as separate graphic instructions.

[dirkschulze]

IMO the common difficulty of <pattern>, <mask>, inner <svg>, <symbol> and objectBoundingBox is keeping track of the different viewports for resources like gradients but even for percentage units. This increases the complexity and the temporarily used memory.

Each of the listed features may have other difficulties as well.

IIRC some authoring tools use xlink:href on gradients. Adobe Illustrator extensively uses it to share color stops. It would not be an implementation issue to skip the optimization but, as said by @jarek-foksa, it could increase file size. Especially for OT fonts, file size does matter.

[litherum]

It’s probably worth making a distinction between the general principal vs any individual example.

In principle, we shouldn’t diverge too much from SVG proper, and the mechanism that SVG uses to represent patterns and gradients is to have an extra element (<pattern>, <linearGradient>) that is referenced by potentially many nodes. Inlining the contents of these nodes into every user of them would probably be too much of a departure from SVG. If we want to have these features, they should match SVG’s design for them, which is to say, be reusable.

Beyond general principle, it’s worth discussing each idea individually.

• <pattern>: All 2D graphics libraries I know of have some facility for patterns, which seems to indicate they are a convenient concept. They can, however, be flattened into individual geometry. However, as the visual size of the pattern shrinks, the file size of the flattened pattern grows proportionately. We implemented patterns in our OT-SVG rasterizer, and I believe it is impossible to implement on CoreGraphics without using SPI.
• <marker>: These should just be additional geometry. There’s no reason for them to exist in the document, because we are not preserving document semantics within the file.
• <symbol> & <use>: These should be considered together. They are tricky to implement correctly, but they are used in lots and lots of content. Presumably that’s a signal that they’re useful. It might be worth keeping the elements themselves, but not supporting all of their attributes (like x=).
• Inner SVG: This is significantly more difficult to implement than <use>, but I don’t think it gives you anything beyond what you already get with <use>.
• Gradients Sharing Color Stops: Not very difficult to implement, and it Illustrator uses it extensively, it’s probably worth supporting.
• <mask>: At least in CoreGraphics, implementing this requires making an offscreen drawing context and drawing into it. Each offscreen drawing context can use a significant amount of memory, either in main memory or on the GPU. These things can be nested, so the memory use could be quite significant, causing us to place artificial limits on how much we’ll mask. In addition, when making these offscreen contexts, we have to determine what the pixel density of the context should be (which might be nonuniform, if the content is under a perspective skew, for example). The masks can theoretically be flattened, but masking n-element geometry with an m-element mask would yield a n*m-element result, potentially causing the file size to explode. Also, implementing flattening would require using algorithms to perform path manipulation which are costly in performance, fuzzy in that they have magic epsilon thresholds which need to be tuned, and still the topic of ongoing academic research. On the other hand, every authoring tool I know of has some facility for masking, so the functionality is probably important. Masks are pretty common in lots of artwork around the world, but I don’t know how that translates into their use in existing SVG content.

[dirkschulze]

@litherum None of the features are essential. Just that Illustrator (or other authoring tools) support some or all features should not be the only criteria to support them.

From implementation point of view, I think (from my experience) that <mask>, <pattern>, inner <svg>, <symbol>, <marker> are not as trivial to implement as it might seem on a first glance.

@litherum What do you think? How should we proceed on this? As you said, there are common and individual things to discuss for each feature. Are there parts where we can get to a conclusion earlier than others?

[chris-little]

As a rather inactive member, I may not understand the scope or use cases for SVG-Native. If not out of scope, how would mapping use cases be addressed, with many repetitions of symbols and text in multiple orientations? And reuse saved what was considered significant storage. One of the powerful arguments for SVG (Tiny) was that text was searchable, unlike most underlying graphics packages.

[AmeliaBR]

@chris-little
The purpose of SVG Native is to define an SVG subset specifically for environments that want lightweight vector graphics but do not want to implement text rendering within their graphics libraries, and do not need interactivity and scripting. The primary use case is for icons and logos.

So, it would not be suitable to represent a full map. But, it would be suitable to represent an individual map marker icon, which could be used as an image by map rendering software that has basic vector graphics support but does not want to implement full SVG support.

[chris-little]

@AmeliaBR Thank you for the clear answer.

[sairuspatel]

For reference, <pattern>, <marker> and <symbol> are not in the OT-SVG minimum subset (they’re in the “avoid these elements” list).
<use>, however, is explicitly indicated as a way to share elements across glyphs in the same SVG doc, e.g. see example 4 at https://docs.microsoft.com/en-us/typography/opentype/spec/svg#examples.

[css-meeting-bot]

The SVG Working Group just discussed [svg-native] Decide whether reusable graphical elements are needed, and agreed to the following:

• RESOLUTION: Patterns are not part of SVG Native
• RESOLUTION: Markers are not part of SVG Native
• RESOLUTION: Symbol and nested SVG elements are not part of SVG Native
• RESOLUTION: Allow use element in SVG Native
• RESOLUTION: Support href on gradients referencing gradients

The full IRC log of that discussion

<myles> Topic: [svg-native] Decide whether reusable graphical elements are needed
<myles> GitHub: https://github.com//issues/689
<krit> ScribeNick: krit
<krit> sairus_: SVG OT spec does not support pattern, marker and symbol
<krit> sairus_: but not banned either
<krit> sairus_: The use element is specifically used as an example in the spec though
<krit> myles: We can probably support patterns
<krit> s/support/agree on/
<krit> myles: Apples implementation is the only implementation as far as I know that supports it and we didn't find any content that uses it. We can remove.
<krit> AmeliaBR: Depends on the use cases for SVG Native.
<krit> AmeliaBR: if the idea is that the files are individual icons or small things in general then Wouldn't expect anything of that to be in.
<krit> AmeliaBR: otherwise I would imagine that you want to reuse shapes to simulate shadows w/o rewriting the same shape.
<krit> AmeliaBR: for patterns there is even more
<krit> AmeliaBR: For patterns, every dot can add a lot of markup in comparison of using a pattern once.
<krit> AmeliaBR: making the SVG larger and less easy to work with it
<krit> myles: file size vs supported features is a trade of
<krit> myles: There is no content that does use patterns for fonts.
<krit> myles: and that makes sense since the files are so small
<krit> myles: there is a point for supporting it on the other hand: 1) there is no wide support for fonts and 2) there is a way to do visually the same w/o patterns
<krit> sairus_: There were discussions to add patterns to the OT table. IT would be a competitive advantage to support it in SVG Native.
<krit> myles: will all implementations update to do it?
<krit> sairus_: Patterns doesn't seem to be a minimal subset. Though SVG Native is not really "minimal".
<krit> AmeliaBR: Myles point is that it is easier to add features later.
<krit> myles: there is a CTPattern... an API to draw patterns in CT. The pattern space is different from the document coordinate space and it is tricky to match the 2 spaces and that part is not in the API
<myles> s/CTPattern/CGPattern/
<myles> s/CT./CG./
<krit> RESOLUTION: Patterns are not part of SVG Native
<krit> AmeliaBR: markers and symbols we were leaning to not support?
<krit> myles: A tool that generates SVG Native file would know the geometry for markers. So we can omit it. Not much markup anyway
<krit> myles: And as far as I know it does not have wide support in OT implementations
<krit> RESOLUTION: Markers are not part of SVG Native
<krit> myles: I think we have to support use. There is much content out it that uses it.
<krit> myles: Apple does not support symbol.
<krit> AmeliaBR: Symbol to me is very similar to nested SVG.
<krit> AmeliaBR: as it affects coordinate system and internal coordinate system. They should be treated the same. So I would say no symbol either. But there definitely are use cases for symbol.
<krit> myles: symbol doesn't let you do what you can't do otherwise.
<krit> AmeliaBR: It allows creating a new SVG viewport
<krit> AmeliaBR: that is why it is similar to nested SVG.
<krit> krit: I would be ok with removing.
<krit> AmeliaBR: use is still useful w/o symbol.
<krit> RESOLUTION: Symbol and nested SVG elements are not part of SVG Native
<krit> RESOLUTION: Allow use element in SVG Native
<krit> myles: gradients sharing color stops?
<krit> myles: we support it in our implementations.
<krit> AmeliaBR: used a lot in Adobes SVG export.
<krit> AmeliaBR: Ai ends up with using lot of gradients but all sharing the same color stops.
<krit> AmeliaBR: shouldn't be a large implementation addition.
<krit> krit: inheritance and currentColor might be the biggest issue but that applies to everything
<krit> myles: don't think anyone considered it
<krit> myles: IMO if SVG OT doesn't mention something it is supported since it is SVG 1.1 minus stuff
<krit> AmeliaBR: It would be useful for fonts to define stops once and use it at different glyphs
<krit> myles: does Adobe's OSS implementation support it?
<krit> krit: it does.
<AmeliaBR> s/at different/at different positions for different/
<krit> RESOLUTION: Support href on gradients referencing gradients
<krit> trackbot, end telcon