Support SVG Native

[twardoch]

There is recent work to define an SVG Native spec, which is a subset of SVG 1.1. Adobe recently published a SVG Native Viewer library (C++ 11), and the FreeType project is considering resvg among the candidates as the backend for rendering OpenType+SVG fonts.

I wonder how resvg relates to SVG Native, and if you have any plans to provide full compatibility to the SVG Native profile?

• http://lists.nongnu.org/archive/html/freetype-devel/2019-05/threads.html#00064
• https://w3c.github.io/svgwg/specs/svg-native/index.html
• https://github.com/adobe/svg-native-viewer
• https://docs.microsoft.com/en-us/typography/opentype/spec/svg
• https://helpx.adobe.com/fonts/using/ot-svg-color-fonts.html

There are some tools that allow people to make OpenType+SVG fonts

• https://www.fontlab.com/font-editor/fontlab-vi/
• https://github.com/microsoft/OpenType-SVG-Font-Editor
• https://github.com/adobe-type-tools/opentype-svg

[RazrFalcon]

Looks like SVG Native is even simpler than usvg. So resvg should already supports all of it, except the SVG 2.0 stuff. I really want to see a comparison table between SVG 1.1 Full, SVG 2.0 and SVG Native, since the current spec is useless.

By the way, usvg would probably be able to convert an SVG 1.1 Full into SVG Native. At least as soon as text layout will be rewritten.

the FreeType project is considering resvg among the candidates as the backend for rendering OpenType+SVG fonts

Nice. Didn't know about that.

[twardoch]

The FreeType movement is very fresh. As is SVG Native and the Adobe viewer.

It all seems to be a result of “de-webification” of SVG. One of the factors is certainly the inclusion of SVG as an alternative glyph representation within the OpenType font format — something that I initiated some 6 years ago, which went through a long party of spec writing and early implementation (with strong involvement from Adobe).

In the first wave, OT+SVG fonts were deployable only @font-face as web fonts in browsers (that already had SVG renderers), but now they're being rolled out in desktop apps and OSes, and it seems that the full-blown SVG is unreasonably much to implement everywhere.

SVG Tiny on the other hand seems to be too limited. The OpenType+SVG did exclude some aspects of full SVG but it seems that OS vendors have now agreed on a stricter subset (SVG Native, that is). My understanding is that this is all work-in-progress.

It’s worth recognizing that SVG actually originated in the late 1990s with strong participation from Adobe, and the Adobe SVG Viewer was one of the earliest implementations. But after the Macromedia acquisition in 2006, Adobe dropped their interest in SVG and concentrated on Flash. Apple’s resistance to put Flash into iOS gradually devalued the Adobe Flash platform, and now we’re seeing Adobe (along with others) pick up their work on SVG after a 10+-year hiatus.

I wouldn’t be surprised if the newly-opensourced Adobe SVG Native viewer was a spin-off of the Adobe SVG Viewer from 20 years ago :)

[RazrFalcon]

I see. I hope they publish a complete SVG Native spec soon, so we can reason about it. Anyway, I think it will be very easy to add the SVG Native to the resvg, since it's already pretty modular.

[RazrFalcon]

I'm closing this until the spec became official.

[twardoch]

@RazrFalcon There is now a W3C Editor’s Draft for SVG Native: http://www.w3.org/TR/svg-native

[RazrFalcon]

The link is 404.

[twardoch]

My apologies, the correct link is

https://svgwg.org/specs/svg-native/

And the current discussion seems to be

https://github.com/w3c/svgwg/labels/SVG%20Native

[RazrFalcon]

Looks like it's just a trimmed SVG 1.1 version (they doesn't even require text), so it should be fairly easy to implement. Probably even with a build option to reduce the library size even more.

[twardoch]

Yeah — it does not use text, and the usage will be in OoenType+SVG font glyphs, or in app UI icons and the like. I think there'll be also interest in a tool that'll simplify an existing SVG to this profile.

[RazrFalcon]

As for simplification, usvg will do this automagically. The current Micro SVG "spec" is basically what Native SVG is.

The main problem is how to reference glyphs, e.g. <g id="glyph13">...</g>.

Also, there a no CSS3 support, so stuff like this fill="var(--color0, yellow)"/> will not work. And it should somehow hook to CPAL...

Also, we should support custom currentColor. Right now, resvg will fallback to black.

But I guess it can be moved to a separate issue, since SVG Native and OpenType SVG are a bit different.

PS: OpenType's SVG spec allows SVG animations, but SVG Native doesn't...

[twardoch]

Right now, OT+SVG does this, but that's sort of hampering adoption of it. The same guys who wrote the OT+SVG spec rather quickly and informally are now working on SVG Native. And I believe the plan is to have SVG Native to become mature, and then switch OT to use just that (or declare that that's the "supported" profile, while other SVG things like animation after not expected to be supported)

[twardoch]

This is something I fully support. While animation etc. in OT+SVG fonts is nice as a principle, in the end it's somewhat useless because there is no way to control it. But at the same time, some software makers are refusing to implement support for OT+SVG because that profile is so sketchy.

That's why, among others, SVG Native was created. When this is an actual solid profile, then makers can make their code safe and predictable, test, and then they can support both the fonts and the nonfont versions of SVG Native.

So I think it's a safe assumption that SVG Native is on its way also to fonts. I worked on the original effort to bring SVG into OpenType (in fact, I came up with the idea, and was then part of the WG). And I know that this was created in a bit of a sprint, to get out the feelers. There were already revisions to that spec.

Fortunately, the real group of implementers of font rasterizers who have already put in SVG support is tiny. So adjustment work will be minimal.

There are also performance issues that speak for SVGN in fonts — if it's a font, it's used in text, and if it's used in text, there may be 1000s of little SVG objects on the page. You don't want to deal with the performance impact of, say, animation.

The rendering pipelines of text aren't designed to refresh all the time. Most apps do caching.

[twardoch]

There is a bit that explains how var() and env() is intended in SVGN: https://svgwg.org/specs/svg-native/#styling

You'll notice that SVGN is written so that it does not completely throw away the needs of OpenType. So my suggestion would be: forget about OT+SVG as it is specified now — we, the font spec people (well, I'm just small fish there) will make the switch from the custom SVG subset to SVGN when SVGN is done.

Those things are all a bit moving targets, but less moving than last year. The FreeType people will also be happy if animation is removed from OT+SVG.

We looked at how variable OT fonts could be married with animated OT+SVG, but the results were tons of very ugly var() stuff in the SVG. It was ridiculous. I want scalable glyphs where you can mix simple colors, bitmaps, strokes & gradients, and that's what 99.999% people want.

And that's what's SVGN is about, and that's where your help can also be of immense value. Thanks!

[twardoch]

Ps. But yeah, I agree: SVGN is a bit different than OTSVG. Let's keep this issue on SVG Native, because that's being done via the standards groups.

As I said, OTSVG will most likely adopt SVGN. They'll most likely still use var() the way it's done now, that's why SVGN has that provision.

[RazrFalcon]

Agree. I will start with implementing SVG Native for now and then we can add some OT-specific stuff.

I can't provide any time frame details since I'm working on other projects right now (they are also related to resvg). But I guess it can be implemented this year.

[twardoch]

Sure thing! (That HarfRust or ReBuzz also looks interesting, though I don't yet know why exactly it's good, but I don't know much about Rust either. But I know that HB's got a bit fat :) )

[leebenson]

Would you be kind enough to provide an update/timeline on anticipated support for this, specifically as it relates to colour/style support in OpenType SVG fonts?

My current use case is rendering an SVG as it looks in modern browsers to PNG. The SVGs I'm working with tend to use OTSVG fonts, with embedded colour/gradient styles. Right now they're rendering as black.

Thanks for an excellent library!

[RazrFalcon]

OpenType SVG is not a real SVG in multiple ways. First, it's a very limited subset, aka SVG Native, which is not standardized yet. Second, it requires an ability to reference random glyphs, which is also unsupported and I'm not sure how it should be implemented. We also have to support custom currentColor, CSS variables, CPAL table...

As for timeline - there is none. I don't have time working on it and it's not a simple task. It could easily take 2-4 weeks.

[RazrFalcon]

Out of scope.