Design a new vector file format

Latest update: https://github.com/flutter/flutter/issues/1831#issuecomment-1012654670

From earlier discussion, some important considerations are:

We don't want full SVG support.  There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter.
We should emphasize in our supported format those operations are effective/efficient/optimized in our graphics engine (Skia).
We may want to process the format at build time rather than support a full run-time interpreter.

Other random thoughts (not all mine):

We really want to avoid supporting a format where there's a preexisting expectation of implementing features that are not going to be performant. For example, implementing SVG will lead people to expect full SVG support including scripting, HTML, SMIL, etc.
We should design our format explicitly very closely aligned to performance features in Skia, e.g. drawAtlas.

Vector support seems crucial for an app framework that supports various screen sizes and densities.  Otherwise you end up with icons that look like this:

Instead of this:

@HansMuller

Kris mentioned this as well: we could do some limited SVG processing at build time. For example we might generate MD icon Widgets based on the SVG descriptions. If done carefully that might save space and increase fidelity to the original designs.

For material design icons specifically, we should investigate using the material design icon font.
@appsforartists For what it's worth, neither Cocoa nor android.view use vector formats for icons.

@abarth Doesn't surprise me about iOS - seems like they started with a hardcoded 3.5" screen and have tried pretty hard to keep that mental model/simplicity of supported resolutions ever since (see: the width of each iPhone being the same, or the original iPad and iPad mini having the same resolution).  I don't know much about mobile development, but that's slightly surprising about Android not being vector-based.
In any case, the icons should not look aliased like they do in the above screenshot, and vectors are a nice solution for resolution independence.  How you guys choose to implement to solve for pretty icons is up to you. :smiley:

How you guys choose to implement to solve for pretty icons is up to you.

Would you be willing to file a separate issue about the resolution issue you were seeing with icons?  @krisgiesing implemented a resolution-aware asset resolver that handles many cases.  It would be valuable to learn about the cases that it doesn't handle.

I'm looking at adding some tests for the current resolution awareness support, so now would be a great time to understand if something's not working right.

It looks like the 3x has a device pixel ratio of 2.6, which we probably don't have an asset for.

I'm looking at this specific case now. The device pixel ratio is 2.625; we're choosing the 3.0x asset, which is expected. However, something seems to be going on during the rendering that is causing some kind of extra aliasing artifacts. So although @abarth fixed the case of the Material Design icons by switching to a font, I'm still investigating on behalf of other types of image assets that need resolution dependent scaling.

I'll open another bug to track this since it's is tangential to support of a vector format.

See #2337

Android supports the "VectorDrawable" format which is just a well-performing subset of SVG. I hope you consider using the same format, given that it already has some community support and the Android team has apparently deemed its performance adequate.

VectorDrawable is certainly influenced by SVG but it's not a subset. Also it uses XML, which pretty much guarantees that it's not going to be the most performant vector format one could come up with. :-)

I was wrong to say that the VectorDrawable is a subset, but it still seems to be a balanced compromise between ensuring good render performance and ease of use. The VectorDrawable specification frequently defers to the SVG specification for key areas like path data syntax, making it much easier to convert and use SVG assets that many developers already use.
I can't imagine that XML is a significant performance blocker because it only affects parsing. It seems to me that render performance - the kind of performance that affects Flutter's goal of 60fps apps - is more dependent on the set of vector operations that Skia will have to draw, not a parsing step that can be done once and cached.
I don't want to belabour the point but I can't help feeling that the work for this has already been done and therefore this doesn't have to be shelved until after a 2.0 release.

We ended up using the Material Design font for the Material Design Icons.  I'm not aware of any obstacles stopping someone from building this on top of Flutter today using direct dart:ui calls or a CustomPaint widget: https://docs.flutter.io/flutter/widgets/CustomPaint-class.html.  We have no immediate plans to build such at this time.

My $.02 on this - even janky browsers can render SVG. The image export option requires creating a minimum of 3 files for each icon or art asset for my team. That's a pretty poor practice when one SVG file can be displayed at any resolution.
For the above comment by Hixie, pre-existing expectations shouldn't inhibit implementing a worthwhile feature. I'd much rather be able to have basic use of SVGs, which solves many problems for me and my team, and find out extended options aren't available than rely on an ever-increasing number of PNGs to accommodate the ever-increasing number of screen resolutions.

I would encourage anyone who wants SVG support to implement SVG support as a Dart package for Flutter.

For those interested, I'd point to https://docs.flutter.io/flutter/dart-ui/dart-ui-library.html which is the low-level library for drawing.

From team: Dart library not good enough solution. Just passing it on.

Can you elaborate on that? The whole of Flutter's framework is a Dart library; anything we implement here will likely be a Dart library. What are the requirements for "good enough"?

Case in point, I implemented a (simple, non-exhaustive) SVG parser in pure-Dart a while back:
https://github.com/matanlurey/svg
It would likely be somewhat trivial to either:
a. Create a runtime SVG -> SvgRenderElement, which uses dart:ui under-the-hood.
b. Create a build-time compile step that converts an SVG into something like:
// compiled from star.svg
void drawStarSvg(canvas, width, height) { ... }

@deborah-ufw if you're interested, we'd love to chat to learn more. Can you email me?

Hi Seth, matanlurey and Hixie - thank you very much for the response. I'm probably not the right person to talk to in depth, since it was our lead engineers who rejected the Dart plugin solution (thus leading to generation of a huge library of png's for our app, which makes most of us cringe also).
I would like to pass the link for this Github issue on to them and ask them to contribute technical reasons for their comment (which was made rather more colorfully than I passed on) - I will do that just as soon as I finish typing.

They're also able to chat with our engineers directly via http://gitter.im/flutter/flutter as well as other contact methods listed https://flutter.io/support/ if needed. :)

I will add that in. Thank you!  :D

Another approach is to integrate something like http://svgpp.org/ at the native level and use the Flutter plugin system to communicate with it. This would probably give you the best size/performance characteristics for full SVG support, but at the expense of maintaining a dependency.

Yeah, SVG asset file import would be really nice but the spec for SVG is over 800 pages long. Having said that to just import static files to render on skia (which is a vector graphics library) shouldn't be a problem. So I am taking it on; as always I can only do work part time on weekends so you won't see stuff right away. Also I have a tonne of SVG files but they all use the same stuff (icon collections from flaticon) so I would appreciate sample SVG files from people that want this feature.
Carlos.

I've been noodling on this a bit over time as well.  Here's what I've come up with:
Engine Level implementation
This seems attractive for the following reasons:

In theory supports something like image: new AssetImage('graphics/background.svg') to have some C/C++ code parse and translate the SVG data to Skia rendering commands
At least one good candidate out there that should be able to plug into Skia fairly easily (https://github.com/svgpp/svgpp) at the engine level
WebKit's SVG logic would be awesome but seems to have far too many dependencies
I don't think librsvg would port too well (tightly coupled to Cairo, transitioning to Rust as a primary language - would need to work out way to get to Skia as a backend at the least)

But it has at least a few difficulties:

Properly handling text
Properly handling CSS (if at all? but adding it is no simple task)
Extending support for additional features (or allowing users to more gracefully add support for features) is challenging.
Seems like it's be very difficult to handle animations

Dart level implementation

Flutter's dart:ui offers a lot of the primitives from Skia that SVG needs already
I suspect text rendering would be much more easily handled at this level than at the engine level
Should be easier for more of community to maintain/extend
Should be able to more cheaply handle direct interaction with the parsing logic (perhaps to handle exceptions and/or animations?)

But has a few difficulties:

May not do much better supporting CSS
May not do much better supporting animations
Would likely be slower (but perhaps not by enough to matter, and could potentially be offset by AOT compiled SVG to Dart code)

@cbazza, which way are you thinking of implementing this?  At this point, I'm leaning more towards a Dart package level implementation.
As far as sample SVGs go, it'd probably be most useful to identify what SVGs are supported from the 1.1 test suite (or, if partially supported, what about them is partially supported).  Those can be found here:
https://github.com/w3c/web-platform-tests/tree/master/svg/import
Or here with some PNG comparisons: https://www.w3.org/Graphics/SVG/Test/20110816/

Also, I think icon type support is probably ly easily handled with something like IconData.  It might be best to treat that separately, as it'd likely only have to support a single path per codepoint

I am thinking of 'Dart level implementation' on top of dart:ui.
2 basic use cases:
(1) load static icon svg files with something like your
"image: new AssetImage('graphics/background.svg')", where the
file could come from the file system or over the network
dynamically.
(2) Widget based svg support with DSX (JSX like construct)
which would look very similar to:
https://github.com/react-native-community/react-native-svg
Regarding 'Test data' I need real files from people that need
this and not the w3 test suite. SVG support would be dependent
upon what dart:ui supports so if a resired svg file contains
stuff that can't be done with dart:ui, I would be able to
find out fast.
Carlos.

I do not think we should go for the react native SVG model.  I get wanting to support real life cases, bit I think covering the w3 suite would give us a better basline of what works and what doesn't and how challenging it would be to implement)

OK, there seems to be some misunderstanding...
When I do (1) it will take standard SVG files and I'll try to support as much as it can given Skia.
When I do (2), which is create widgets to handle SVG like constructs it will look very similar to that react-native-svg library. These are 2 very different things.

@cbazza the use case for svgs in our app is mainly for one-color svgs we use as icons. Here is a link to a zip file on Dropbox with a selection of recent svgs that are representative.  https://www.dropbox.com/s/dp38wxc22625cvc/icons.zip?dl=0

Thanks for the interest in helping here, I would be happy to see an SVG Flutter plugin coming to life!
I wrote a tool that does some minimal parsing of a sequence of somewhat-SVG files and dumps out Dart files that we later use to show icon animations: vitool.
I used this tool to create the AnimatedIcons data, you can check the result by running the manual test app (cd dev/manual_tests; flutter run -t lib/animated_icons.dart).
It is far from being optimal or complete, but works for the current set of animated icons we have, and someone should feel empowered to fork/extend it.

@deborah-ufw for these single color icons something you can do is create an icons font, and show the icons using the Icon widget.

@amirh doesn't seem to be easy to create color vector fonts

@amirh if you read the whole thread above, creating and defining a font with glyphs as icons is an extra series of steps that has to be taken because SVG is not supported. SVG support is much more efficient than a font. Also, zoechi is right - any vector art that has several colors is nearly impossible to make into a font.

Sorry - I looked at the sample icons and thought that you only needed single color icons.

@deborah-ufw, thank you for the files, exactly what I was looking for and already found stuff that my files don't have.
@amirh, yes I have seen your great work already ;)

Do we finally I have a straight way to source an svg or vector asset xml into the image for flutter

@Hixie: please (re)consider that for multi-platform native mobile teams this is a real pain point, but that only partial, relatively simple SVG support is needed to solve this. Towards the SVG standard maintainers this could be considered half-hearted, but Flutter is for mobile developers, not for general standards authors. Flutter would win the hearts of mobile developers if it alleviates their very real pain, even if only in a pragmatic manner.
Please also consider that despite this long-existing need, the community support approach has failed to produce workable solutions in Flutter competitor Xamarin (in my 5 years of Xamarin experience - libs can't handle design tool exports, are too limited, not stable, paid and/or closed source).
Because of this I am not optimistic that the Flutter community will succeed where the Xamarin community failed. I do estimate that a practical. partial support for SVG icons is something that the Flutter team could deliver, using existing Skia primitives.
This would fit the Flutter goal well: enable mobile developers to deliver high-quality, high performance UX in record time. It would improve productivity, fidility and performance (an SVG loads a lot faster than all those PNG's; icon SVG's typically have modest computational cost because a requirement for visual clarity quite often leads to a shape of modest complexity).
The core need is for a productive workflow from commonly used creative designer tools (such as Adobe) to scalable native app icons.
The current PNG approach is very wasteful in terms of productivity and app size; it is just so primitive to generate and ship every icon in up to 9 fixed bitmaps (6 Android, 3 iOS) that are then post-processed at runtime. The problem increases steadily as resolutions increase in size and variation.
It sticks out as a sore thumb in the otherwise delightful innovative and productive Flutter developer experience. I think Flutter has a real opportunity to win devs hearts & minds here,
Also @dnfield the above mentioned SVG features that are mentioned as obstacles for implementing in Flutter are in my experience either not relevant or are rare enough that falling back to PNGs for those design assets is a minor inconvenience.
Don't cares: CSS, HTML, SMIL, Document Model
Text: rare enough to fall back to PNG sets for that
I hope the length of this comment conveys how much value a solution would have. Hth!

@VincentH-Net I am 100% with you because I feel the pain too !!! Please send me some of your SVG files. Perhaps Xamarin struggled to deliver SVG support due to lack of vector graphics engine that could handle it; this is not the case for Flutter with Skia so I am very optimistic that a community solution will happen.

FWIW, Xamarin also has Skia available in SkiaSharp.  SVG can be tricky even for minimal implementation.
But @cbazza I'd be very interested in collaborating with you on this

And on the animation front, I think that enabling Lottie would satisfy a lot of use cases (and probably do it with better tooling for designers).

@dnfield I think these Lottie animations can easily be rebuilt as Flutter widgets

@dnfield, excellent you could be the low level guy handling changes in the engine level while I do the upper level work on widget (async svg parsing, 'picture' construction that can be cached and sent to canvas on rendering updates, etc).
yes, Lottie working would be great for designer/developer workflow.
@zoechi why rebuild something by hand with widgets when you can simply import a working Lottie widget that handles everything for you? Having said that my previous goal (2) above would work great with widget animations (hence why I want to do it too).

@zoechi - the goal would be to enable designers to create such things and render them with minimal effort on the developer's part.  A secondary goal would be to enable loading them as resources at runtime, rather than necessitating precompilation.
The same is true for SVG - yes, a developer could certainly convert SVG vector data to Dart, but ideally you can just include a vector drawing (SVG or not) resource and render it at runtime.
In other words, I want to be able to tell my designer to create a vector asset once and be able to use it in my Flutter application with minimal modification (and without having the designer export it 5 times in various raster formats that will end up being invalid as soon as Apple or Samsung release their next phone).

various raster formats

yeah, that feels like the previous decade

https://github.com/luberda-molinet/FFImageLoading Might be worth looking at, uses Skia to render SVG for Xamarin
@escamoteur

Thanks, that looks really good, only thing missing is that it is not async ;)

I'm using only vector drawables in Android application recently, and I don't see any noticeable performance penalty. Icons are sharp and app size is a lot smaller. It's also much easier and faster to test different images. This @2, @3, @4, @5,.... solution looks like a huge step back in such a modern framework as Flutter is.
I don't understand why you just can't go to the team responsible for android vector drawables, and use their ideas or implementation (if possible) on solving that problem.

I've been toying around with some SVGs being drawn on a canvas here.  path elements are probably the trickiest to implement, but there's a Skia API that would really help if exposed.  I've experimented with exposing it in the engine and will open a PR once I've had a little more time to refine it.
The rough idea would be something that allows us to create a dart:ui Path from an SVG data string.
That still leaves some work around parsing out the various transformations/strokes/fills that can be applied.  I think we can borrow a good amount of that from work @amirh did (I didn't borrow all his path parsing logic because it seemed like it might have constraints SkParsePath doesn't and like SkParsePath should be more efficient since it will require only one round trip to the native side to draw the path rather than round trips for each drawing command).
See https://github.com/flutter/flutter/blob/master/dev/tools/vitool/lib/vitool.dart, https://github.com/dnfield/flutter_svg (which is currently capable of rendering the two SVGs included in that project to a canvas), and https://github.com/dnfield/engine/tree/path_svg (which is currently also including my PathMeasure/PathMetrics related work for Lottie).

Hi @dnfield ,
Here is my take on your initial implementation. Let me just say that whatever I am going to say should make no difference to your enthusiasm and coding progress. The more you do the better because we can always use it later.
The problem I have is architectural and here is why. In order for UI to be responsive at 60 frames/sec, each frame only has ~16ms to run before blocking the UI. So let's assume half is used by Flutter to do it's thing, that leaves 8ms for our SVG parser and there is no way to parse any SVG file and generate image in that period no matter how powerful a phone/tablet you have. So best thing to do is to target slow devices and have async code that is able to do this using multiple frames but the key is that each frame can only run up to 8ms and then it must return and pick up on the next frame.
So you can't parse the XML using dart:xml because it is not async, it will block until the whole file is parsed. Also generating the image should be async because you can't do everything in 8ms. There is no point in prematurely optimizing the code though so write the best code that can be read. I have a plan that will work but it will take some time so I want you do continue as you are because I can always take your work and use it later. My design plugs into the current image loading functionality (AssetImage & NetworkImage) and the user just needs to specify a '.svg' instead of '.png'.
Carlos.

@cbazza just an idea: Parsing could be done in an isolate. I think there was some work done to be able to communicate with message channels from isolates others than the UI isolate and to pass data between isolates by reference instead of copying (not sure about status or progress though)

@cbazza  - thanks.  I don't think that dart_xml is the best solution for this, but it works and enables some progress around the drawing logic (and I didn't want to block this completely while working to implement an async XML parser).  I also started looking at implementing ImageProvider, but I figure that can be an implementation detail we can obscure from the users.
I am in no way set on any of this API.  But we can at least start on drawing SVGs, and probably support simple ones on decent phones.
Are you intending to work on the XML/SVG reading/parsing API?

@zoechi - we could still achieve much better memory usage and probably better parsing time with a streaming reader model.

@zoechi yes I looked at isolates but you can only pass primitive values (null, num, bool, double, String) and lists and maps, and not objects and/or object trees, so async route seemed better. Another interesting thing about figuring out async xml parsing is that the concepts would apply to any async tree processing, like for example the widget or element tree. This would enable async reconciliation for example like in React's Fiber :)
@dnfield yes I am working on async xml/svg parser/processor.

just wondering, rendering SVG using a web-view can be an option?

Too heavy for simple buttons and I am not sure the webview will be able to handle 60 frames/sec changes. I mean let's say we move the icon around or scale it for example.

I'm not iOS developer, so I see now that also iOS 11 has support for vector assets. It's not SVG, but PDF. Is easier to support PDF vector assets?

No.  Quartz has a lot of historical ties to PDF for its internal rendering system, which makes it easier to do this on an iOS device.  Skia is not a PDF renderer, and the file format would (IMO) introduce a lot of ambiguity about what's supported and what's not (with not-as-good tooling to fix it available).

PDF is more complicated than SVG and the PDF/X subset (which is used for vector assets) is designed for printing. I would love to see PDF rendering support on Flutter though but for us let's stick to SVG.

I'd be happy with mere VectorDrawable subset of svg (point, line, curve, fill, move).  Flutter allows for RAD and aims to be truly multiplatform (with desktop coming) but now it can not. Both Android and Apple platforms are present on 60"+ 4HD screens. There vector graphics is a must.
P.S. Excuse me, but without VG your (flutter team) work is going to vanish in wake of Kotlin working natively on many platforms including iOS. Sure Kotlin native its still in beta but so is Flutter. :(

@ohir Please explain how you would write a cross platform view (single code) that works both on iOS and Android with Kotlin native. Unless you intend to make a kotlin version of react native widget abstraction?

Let's not underestimate what the Kotlin native people will do because the possibilities are endless. I got to Flutter from my experiments creating something like Flutter using Cocos2d-x. They could use that too and/or React Native and/or Flutter because everything is open sourced and available for cross pollination :)

Yeah totally agree, kotlin love and adoption from developers is huge and cross platform compilation makes possibilities endless. But the comparison between Flutter beta and Kotlin native beta for mobile cross platform today is pointless.
Anyway, deviating from the subject.

@lukaspili So far there is anko for Android. Its layouts DSL could work intact also with apko*, linko* and winko* included in respective platform subtree. But this is OT for the Flutter VG issue. [* does not exist yet].

Thanks for all the passionate conversation! We'd like to keep this issue focused on the use cases and requirements for vector formats and APIs. Thanks in advance for staying on topic! :)

What do people think of splitting this into an issue for supporting SVG and keeping this one for some TBD flutter vector format?

That would make sense to me; the original issue is phrased as a Flutter-specific vector format of some kind.

@cbazza Hooray for svg-like support.  How should I send them to you?
Would love to try moving to flutter but generating a zillion pngs is going to seriously bloat app size and look ugly.

yes, please send me an URL to look at the files.
Carlos.
<EMAIL_ADDRESS>

So at this point, on this front, I'm pursuing a Flatbuffer based approach.  I'm working on defining a Flatbuffer schema that could capture vector drawing commands - more or less the way Skia captures paths.
I could see this being semi-interoperable with SVG (e.g. have a SVG -> Flatbuffer conversion tool, that could cover many of SVGs use cases), and avoid a lot of the performance hits that we'd face with SVG (lack of streaming XML parsing, need to parse SVG path data and then send it to native bit by bit).
It should also be possible to give more clarity up front in the conversion tooling about what features are not supported in a given SVG (e.g. "ForeignElements are not supported by this format").
The Flatbuffer parsing bit could be done in Dart or C++ - the one thing in dart is that it'd still be nice to have some way to batch commands over to Skia for building paths and drawing on Canvas.

Is there a way to run vitool at project level? I can create the generated file but it needs access to lots of private classes that prevent me from adding the .g.dart to my project.

@emilieroberts Thanks but those files are not in SVG format but rather on the custom android vector format which is very similar to SVG.

@cbazza oops, indeed - most of the svgs are up there now :)

@cbazza can you clarify what you mean with custom android vector? They have an <svg tag, unlike android vector drawables.
Whatever it's being done with vitool at the moment is amazing, but I couldn't find a trace of documentation anywhere. I can write it an example with AnimatedIcons.arrow_menu, but I'd also like to know what it would take to do that from assets from outside flutter SDK.

@fmatosqg you are right, the code that's used to run animations generated by vitool is private to the framework. The reason is that there are still open questions around what would be a good vector format for Flutter (as tracked in this issue), and I wanted to avoid a public API that supports any specific format (as that will be committing to that format if we don't want breaking changes in the future).
The current API surface for AnimatedIcon allows us to use files generated by vitool internally in the framework, and still be able to replace the underlying implementation and vector format without breaking any client.
If you want to generate files with vitool and use it in your project, you can do it by copying the code from packages/flutter/lib/src/material/animated_icons and including it as part of your project (this also guarantees that your project won't break if we change machinery the used by AnimatedIcon).
Sorry for the inconvenience and hope we get a better solution soon.

I like this idea, specially if https://github.com/flutter/flutter/issues/13834 goes forward.

So FWIW, in flutter_svg I've formulated the code such that all the drawing is really done by intermediate objects.  The SVG related work is basically mapping SVG to those objects.  There's still work to do to get that intermediate format fully stabilized (for example, I've started on text support but it is very bad right now).
I've started porting over support for Android Vector Drawables into the framework (minus support for external color and style references etc., and not yet supporting clip paths or probably some other features).  It should be entirely possible to support Shiny this way as well, or really any other format.  I like working through SVG for it at this point because it helps cover a lot of interesting cases to support, so that's my primary focus for now.

After reading this thread -- and a long one about JSX support -- I can't help thinking that there exists a governance issue. The Flutter team risks being pulled in a thousand different directions as developer's clamor for what they feel is important. Perhaps Flutter should institute "incubator" projects, like Apache. Requested features are implemented by plugins, in an open-source manner, possibly with contributions from the Flutter team themselves. If the plugins achieve sufficient support, efficacy and popularity, they become candidates for inclusion in the core Flutter framework.
I feel this would let the most vocal developers put their "code where there mouth is" rather than resorting to the chest- and brow-beating on display here, and would leave the Flutter team more free to concentrate on core engineering.

I respectfully disagree.  Also you can know what they don't consider urgent if you look at other milestones down the road.
Also the reason to have something added to the flutter core should be more than "I can do a plugin and it works for everybody and everybody wants it". That's a reason to create a plugin, but not enough to be added to this repo or other flutter repos.
An example of things that should not be plugins: things that @dnfield added to the engine so he could benefit and use from the plugin he owns. Such plugin would have no chance of doing all the features it does if they were not added to the engine.
Being vocal is important, but will never guarantee that it will go through. Putting the code where the mouth is is also important but still not enough. This project has a lot of transparency and they clearly listen to what devs say, but it is not a democracy and doesn't mean popular vote will win without reasoning about consequences.

Yes, please don't be concerned that the developers working on Flutter's framework will be distracted by discussions on bugs. :-) We do read the discussions, and we care very much about everyone's opinions, but at the end of the day we have clear guiding principles and we're not going to just react to the loudest voices. We perform careful market analysis to determine what the community as a whole cares about.

Interesting conversation that leaves me with a simple question. How does Flutter team recommend we go from design phase (SVG) to vector graphics in Flutter?

@lukepighetti you can try https://github.com/dnfield/flutter_svg and check how far it takes you.

Personally I am not happy with the solution offered for SVG files in Flutter. I used flutter_svg package and I'm not happy with it.
SVG support needs to be supported natively in my opinion.

@socialmammoth can you elaborate on what deficiencies you're seeing?

One thing I've been mulling over for a while is whether it'd be worthwhile to support the .skp (SKIAPICT) format.  I think there are good reasons to not do this directly - the format is not guarnateed to be stable from version to version of Skia being the big one.
However, it does have some interesting properties - in particular, it's possible to get Chrome/Chromium to generate an SKP (perhaps of a rendered SVG), and it's very likely that we already support most or all of the Skia drawing commands required to actually render the vast majority of SKPs.
I've been planning to create a code-gen type of solution for the SVG plugin, so that you could generate Dart/Flutter code from an SVG.  I think at this point that it would probably be more interesting to investigate an SKP to Dart build process - some of the code written for Flutter SVG could be ported over to the framework (e.g. the RawPicture and related infrastructure, which roughly corresponds to a RawImage), and we could wire something up that would take the output of an SKP (perhaps generated from an SVG as rendered by Chrome, which is pretty much gold standard for SVG rendering anyway).  It should be possible to make tooling that would take an SVG, invoke headless Chromium to render it to an SKP, and then transforming the SKP to some Dart file(s) that Flutter could render at runtime.
One large area this doesn't solve is dynamically loading a vector graphic at runtime (e.g. SvgPicture.network), but I'm interested in feedback on whether this would still be a worthwhile/acceptable solution even with that limitation.
I also say this with the belief that, at this point, we will never get "native" support for SVG in Flutter.  This is partly because SVG itself has a lot of baggage (XML, CSS, ability to fetch external assets) that are non-trivial to implement outside of a browser/HTML rendering software and would add a lot of bloat to software we're trying to lean down.  It's also partly because it's entirely possible to implement quite a bit of SVG without making any huge changes to the framework - although a few things (filterEffects and textPaths in particular right now) will probably benefit from some more tweaks to the engine.

I would like to see Flutter support SVGs natively because that is what front end devs expect from their frameworks in 2018. I would like front end devs to find Flutter accessible, because I want the ecosystem to grow.

@dnfield > .skp (SKIAPICT) format. I think there are good reasons to not do this directly - the format is not guarnateed to be stable from version to version of Skia being the big one.
IMHO interesting approach. But then Flutter tooling (at least in AS) need to seamlessly deal with conversion. Designers are somewhat used to restrictions imposed by current Android's vector-drawable imports, so they surely will be able to deal with other set of dos and donts.
For the casual developer the manual should read: "Drop your svg drawings here, annotate here, use at will. If your svg does not abide to supported SVG subset (see here) compiler or analyzer (flutter analyze) will tell you what is wrong in your svg". Or something like that.
dnfield > get Chrome/Chromium to generate
Good for PoC and testing, but real solution IMHO may not require such a huge dependency -- and one that is hard to script as CI middle step. Of course at the beta and then as a second 'hard way' it might be ok -- eg. to get easy animated drawing that skPicture allows for. I may be wrong ofc. as designers usually have a big bucket with browsers under their laptop flap. Nonetheless, mind that artwork mutates often. Not only at prototyping stage but also as launch time approaches and devs are in bug hunting fever.
[Ie. We either need a flutter tools deal with conformant svg import or we need a way where chromium is entirely at designer's hands. Not developer's.]
PS. The launcher_icons package way might do at start:  flutter packages pub run flutter_svg_to_skp:main -i path/to/svgs -o path/to/skps.
-- my ¢2

@cachapa >  being able to load SVGs directly from the network
This is a work for a separate huge package that will deal with validation and workarounds
around possible incompatibilities and producer's quirks.
First get engine to draw developer's supplied vector format that "Load SVG from network" package will surely use. :)

Just to be clear @cachapa  and @ohir - flutter_svg already supports loading an SVG over the network (SvgPicture.network).  However, that package will never end up supporting the entirety of the SVG specification - the goal is really only to support enough of the specification to render most SVGs.  It already does that, with the major exceptions at this point being fliterEffects (so no blurs, color filters, etc.) and a lot of text related support - but there are some others (markers aren't supported, certian types of xlink:href references still aren't supported).  There are also some issues that I am intentionally not supporting, like the full CSS specification, scripting, and interactivity.
@lukepighetti I think that expectation only really exists with web based front end developers. Qt supports SVG, but only a limited subset.  GNOME supports a bit more with librsvg, but again that has some issues (and it's really difficult to use outside of Linux environments).  I'm excited to see what happens with resvg, but I don't know of any GUI library that's integrating it.

@dnfield I don't want to criticize your work since you did a great job and I thank you tremendously for that. I'm just disappointed that color does not work as expected. I had to pick my own color, I'm not an artist, I'm also colorblind.
Flutter needs to support SVGs the same way modern browsers do. It's a must. We need to be able to use assets copied or imported directly from a web page without modification.
Frankly thank god at least there's a package, but we need color, we need effects, if performance is an issue than make it  optional for people to turn features off not force them to turn features on.

We need full spec support for SVGs

Even @yjbanov mentions it in his article here: https://medium.com/flutter-io/hummingbird-building-flutter-for-the-web-e687c2a023a8

Even Chrome doesn't support all SVG features and especially right-to-left text rendering is buggy (without any progress in last few years). In other words, I don't think the full SVG support is realistic. SVG-static seems to be a reasonable subset. In flutter_svg I miss text hadling (incl. text on path), filters and masks. It would be nice to have support in Flutter for building something like this https://drifted.in/horologium-app/

@SocialMammoth

Flutter needs to support SVGs the same way modern browsers do

No. Flutter apps need to be lean. This issue is not about almighty package to deal with all of SVG, it explicitly says "support a vector drawable format" (not support SVG). The goal, as I understand it, so far is to get all flutter apps rid of bitmap assets as much as possible. And that on the engine level. @dnfield did a great job via a package. Now its time to just get some vector graphics available from Dart without ballooning the flutter (skia) engine or the app itself. The .skp use seems a good choice for that goal. It already allows for more than Android's vector-drawable does and it already is in the engine. Designers will accommodate to its feature set.

@ohir I guess we disagree then. A front-end framework that doesn't support SVG files is a bad joke really.

Well, I don't think flutter NEEDS svg to be useful, but it would be nice. And if not svg, than some format that is easy to obtain from your typical vector graphics application.

Basically SVG is the standard vector format to use here but we can't possibly expect support for every feature of SVG. The goal has always been to support the minimum in order to import vector assets from typical vector graphics applications. Which vector graphics applications can read & write .skp ?

@lukepighetti : Dan's idea is to use engine's internal format. The crux of this solution is to get SVG converted to the format the engine understands. It does not matter if Inkscape knows this format as long as any viable converter does exist.
I was in doubt yesterday, but today, after a bit of research, seems to me that chrome automation is well supported. If headless chrome can be used with a rendering proxy it can be made a svg->skp converter too. A bit heavy, but affordable. Low hanging fruit indeed, @dnfield :).
It all fits nicely with goals set by @Hixie almost three years ago.

Skia seems to support SVG. Why doesn't Flutter provide SVG support directly?

From what I can tell the Flutter team wants to keep the Skia package size as small as possible. I did not know that Skia supports SVG, but if it does, that is low hanging fruit. As a note, there is another issue on adding Lottie support fo Flutter because Skia supports it.

Skia does not support importing drawings from SVG, but has some experimental support for creating SVGs (which isn't as useful here).
And yes, package size is a concern.

For people who are interesting in a vector graphics format, I am curious about your use cases.
I am aware of these so far:

Icons. Static images that may need to be recoloured dynamically (e.g. grayed out when disabled), and may need to have varying levels of detail depending on the target render size. Unlikely to have text.

Animated icons: Two icons as described above, and a description of how to seamlessly transition from one to another.

Backdrops: Images that may be much larger than the screen, maybe shown with parallax; generally simple scenes with shapes, gradients, and shadows, unlikely to have text.

Are there other use cases that motivate your need for vector graphics? Please describe them here. Thanks.

Supporting multiple resolutions with a single graphic, particularly with forwards compatibility for higher resolution screens

My app is basically a companion to a conference. I want to include maps of the hotel, with the ability to pan and zoom. Using a high-resolution raster is impractical for size and performance reasons; vector graphics are perfect.
Right now I'm using an embedded PDF webview, which is super inconvenient and only works online (though I could probably work around that if I had to).

Custom 'look-alike real' knobs are practically unattainable without vector graphics. Especially ones that rotate, skew or melt.

To add to what Dan has said: mere 1kB of vector source can produce fine detail, smooth picture both on 7" tablet and on 105" 4HD TV. Recent case from cash register Kiosk app for 10 or 14" (cashier facing) and 5 or 7" (customer facing) screens. Set of all 5000+ vector drawings of goodies was less than 5MB in size. Just 'vegetables' subset (~150) of it converted to pngs for exact two screens used was over 30MB. Full inventory set might end in GBytes range.
P.S. Next big thing would be to have vector graphics with touch regions defined, eg, via a chosen fill. This would have spared thousands lines of code for the whole class of mostly static but detail rich interfaces.
As in interactive Machinery Operator's Manuals.
Dreams aside - just let our designers use simple vector drawings first :)

Thanks for the feedback so far. Very helpful.
@ohir Can you elaborate on "rotate, skew or melt"?

My workaround for this that I'm actually very happy with is to use the path_parsing package (https://pub.dev/packages/path_parsing) to generate canvas drawing commands from an SVG path string and then using those to make a CustomPainter widget that draws it. For other SVG shapes besides paths (rect, circle, etc.) I just manually translate them into drawing commands which is a little tedious but not too hard.
This works really well for simple vector icons and allows you to use the same widget with different sizes and colors throughout the app.
Here's the code: https://gist.github.com/jpotterm/7b30739e0af722baf97a397d9841d908
It could be really useful if there were an official flutter command line tool that parsed an SVG file and produced canvas drawing commands that would produce a similar result.

@Hixie
Eg. https://dribbble.com/shots/1083175-Air-conditioning-controller#
Central rotating knob and the gauge around it can be meticulously drawn with current Canvas API but it can also fit in 2Kb (xml svg) then circa 300-500B of drawable. Were vector graphics and rudimentary affine transformations from the Skia level exposed via some 'vector graphics' interface, this knob could be made alive just with applying fills to the gauge segments and rotating a path of the indicator small circle.
More important is that this whole knob, with colors and other details would be drawn exactly as designer planned - because it would be all her work just embedded. Interface of Vector drawings + fill + gradients + good designer may looks like:  https://www.artua.com/app-design-deckadance/
Affine transformations at the developer's part will make such a design responsive and vibrant.
As for skew, and shear transformations: can eg. be used to model an control lever shifts.
("Melt" word-shift likely induced by Salvadore Dali's ghost ;)

/off-topic/

@jpotterm
It could be really useful if there were an official flutter command line tool that parsed an SVG file and produced canvas drawing commands that would produce a similar result.

I have produced something similar. Code generator that looks for an Annotation and, takes the specified SVG PathData and generates a getter that returns a Path object. If people want I could clean it up and open source it.

The app I contribute to is perfectly suited to vector graphics.  These can be tinted and resized.
Doing this in multiple colours at all different densities would be awful to do, unsustainable, and make the apk giant. These images come from hand-drawn graphics.

Thanks everyone for your feedback. Very helpful comments.

For people who are interesting in a vector graphics format, I am curious about your use cases.

Another use case is basically anything that needs dynamic graphics:

charts
loading bars
drawing
etc

I'm actually very surprised Flutter does not support that since Skia has support for a subset of SVG (the useful parts anyway).

I would like to use SVGs for art. A quality full screen PNG can be 1mb or more, while it's equivalent SVG can be 5-10kb. For programmatic graphics I'm a huge fan of CustomPaint so I would never use SVG for things like charts, loading bars, drawing, etc. For those who are concerned about CustomPaint API, it's mentally a lot like HTML Canvas API.

If your going to support SVG, then you have to support all the SVG features, like gradients, strokes and more. This wasn't done in the Android project and that raises some warnings flag for developers, since almost all the others dev. platforms support SVG and vectors. It's the basics of graphics, do it right!

@harounhajem please see https://github.com/flutter/flutter/issues/15501 for that topic, as well as https://github.com/dnfield/flutter_svg

fgdgfdg

@PierBover for charts specifically please consider https://pub.dev/packages/charts_flutter

I just jumped into Flutter. I was refactoring a personal app from Ionic 3 to Ionic 4 and it was (again) totally different and it required an app from scratch.
So I decided to move to Flutter and give it a try. As I said, I had this app finished and working and this includes a lot of graphics and icons that I had ready on my app. I'm not a designer and I need to pay for this designs.
I understand I'm not the only one on this situation, wanting to reuse his SVG assets.

@erperejildo - see https://pub.dev/packages/flutter_svg

Thanks @dnfield that works perfectly (not sure why is not this closed then)

(not sure why is not this closed then)

Because the actual issue—support a vector drawable format other than SVG—is not solved?

oh, my fault @jonahgreenthal. I came here looking for SVG support and saw that the third comment was asking for the same thing

Uber has done this for iOS: https://github.com/uber/cyborg
It would be interesting to see something like it in Flutter.

Any updates on this?

@dnfield that worked fine displaying an svg as new widget but it doesn't work with AssetImage property. I need to display it using a CircleAvatar widget

@Hixie there is also a use case where svg icon need to have multiple color as it help the user to understand the meaning of the icon. So I hope the solution will include the ability to customize theme color as well.
Currently, some people suggest to convert SVG into font and use it the same way the icons package did however we cannot have multiple color in the icon in this case.

4 years of various comments without any useful solution. In short - no, not, possible.

Can we at least know why is this so problematic/difficult?

Flutter_svg has decent support for SVG in flutter.  Rive also supports a vector based format for flutter.
This issue is about creating a new vector based format.  That takes time :)

@dnfield there are some widget with background properties that we cannot pass svgs. Is there any way to archive this?

SVG in general will only ever work for some use cases too. :-)
This specific issue is about having a non-SVG vector graphics format. If you have a different requirement, I recommend filing that as a separate issue.

From earlier discussion, some important considerations are:

We don't want full SVG support.  There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter.
We should emphasize in our supported format those operations are effective/efficient/optimized in our graphics engine (Skia).
We may want to process the format at build time rather than support a full run-time interpreter.

So how does someone go about creating a new vector format for images in flutter. Based on above I think that's what is being suggested...

Maybe the guys over at Rive can put together some SVG converting library. They already have a proprietary vector engine for Flutter.

Why not to add support importing svg into Flutter project. And convert to dart code/new vector drawable etc. Note that the same situation is on native Android, that's why we don't use svg directly (which I agree does not make much sense) and import to project instead, svg is stripped from not supported and not needed functionalitites and converted into android path definition.
Isn't that good idea for Flutter?

@giaur500 This issue isn't about that. If you have a suggestion specifically about SVG, please file a separate issue.

To be fair, many of the comments in this issue are discussing SVG and Flutter.

#follow
SVG is perfect for great pixel-level user interface. Properly the best so far for great pixels.

@lukepighetti Yes. They are unfortunately all off-topic and having them here will not result in any improvements to Flutter.

From earlier discussion, some important considerations are:

We don't want full SVG support.  There is too much in the spec that is expensive, heavyweight, and/or duplicates what we already have in Flutter.
We should emphasize in our supported format those operations are effective/efficient/optimized in our graphics engine (Skia).
We may want to process the format at build time rather than support a full run-time interpreter.

A build time tool would be great, take the vector and render all the screen densities, and add the assets as images. Apples iOS does this with PDF icons.

Better to be able to import svg and process them internally, either at build time or auto generate code during import. Similar as native Android - you can import svg and Android path definition xml will be generated from source svg. Import into Flutter project could generate dart code to be reused to draw vector asset.

i like it

@giaur500 This issue isn't about that. If you have a suggestion specifically about SVG, please file a separate issue.

New issue has been created: https://github.com/flutter/flutter/issues/63752

So what's the state of this?
Is there any intention at all of supporting something similar to VectorDrawable, or even VectorDrawable itself for those on Android?
As a developer considering adopting the ecosystem, I'd say this is a strong point that'd convince me to stay native..

I never tried it myself, but flutter svg lib used to have support for at
least key features of vector drawable like paths.
On Sat, 15 Aug 2020, 19:46 n00bmind<EMAIL_ADDRESS>wrote:

So what's the state of this?
Is there any intention at all of supporting something similar to
VectorDrawable, or even VectorDrawable itself for those on Android?
As a developer considering adopting the ecosystem, I'd say this is a
strong point that'd convince me to stay native..
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-674375846,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABI4Y4LWYSYEIWI3RRSSCK3SAZKO5ANCNFSM4B3FXMMQ
.

I guess state is nothing. No conclusion exists here from this thread and also  my idea to develop something similar to native vector drawable closed immediately.

Is there any reason why the flutter svg package won't work for you? We are using it with great success in one of our apps.

It seems the flutter_svg package is worth a look for this kind of use case..
@lukepighetti how would you rate its performance? My usage would be just a splash image and a few icon-sized graphics here and there in the app, so nothing fancy.

It seems the flutter_svg package is worth a look for this kind of use case..
@lukepighetti how would you rate its performance? My usage would be just a splash image and a few icon-sized graphics here and there in the app, so nothing fancy.

I would rate it very high for your use case. I think people should really give it a try before they put pressure on the flutter team to do something internally.

Unless I'm missing something, the implementation for such a flutter feature would look a lot like @dnfield 's flutter_svg package and solves the use case you are describing. On top of that, the maintainer is on the core Flutter team so we can be sure of its quality.
If there is something I'm missing please feel free to educate me so I can learn more about this topic.

@lukepighetti
I think that "not SVG" in the issue's title should be made red, bold and flashing.
This issue is specifically not about svg format.
OP (and me) had hopes for exposing Skia's path api so the assets graphics could be represented in a compact form - ie binary of fixed endianess. Dan even did a patch to Skia that works for the flutter_svg, which in turn now allows us to use svg assets. Though still we parse xml at app run time and draw by calling the engine — also for the static assets bundled in the apk.

With proper support for the custom vector drawable format (lets name it fvd), parsing of designer work would happen once — at app build time, then object in fvd format would be thrown directly at Skia. In graphics-heavy app such approach would have enormous effect on the app size and noticeable savings on rendering time. [citing self]

I hope that above shows how I see this issue and justifies my call to have it at last done.
Even as a part of the flutter_svg library.
Flutter deserves to have yet another advantage over competing technologies.

For what it's worth, there's nothing inherently wrong with using flutter_svg, it's just that it's lacking even some very simple things, e.g. it doesn't support percentages and straight up crashes when trying to render them. This comment is not a knock on the flutter_svg library, it's just to explain to people who are saying we can just use flutter_svg.

flutter_svg seems work very well despite of not support scripting, HTML, SMIL etc.
it's looks good and we can build SVG from files assets, network or ordinary strings.

my problem with flutter_svg is, that it only supports android and ios. I think it is crucial to have svg in web and native as well.

SVG images are no longer supported in web from today new beta version.
We really need a solution to this, I can't find a proper way to use svg images in Flutter web.

flutter_svg works if you use the CanvasKit backend. Unfortunately, the html backend is missing a few features that flutter_svg depends on.

@dnfield what feature is missing, do you have an issue filed?.

The big blocker is Canvas.drawPicture, which has a bug here: https://github.com/flutter/flutter/issues/48491
Things more or less work on the CK backend though.

flutter_svg works if you use the CanvasKit backend. Unfortunately, the html backend is missing a few features that flutter_svg depends on.

Yes but we can't really force de mobile browsers to use CanvasKit, as it is way more heavy.

can't we just add an kIsWeb switch?
Francesc Arolas<EMAIL_ADDRESS>schrieb am Sa., 6. Feb. 2021,
14:34:

flutter_svg works if you use the CanvasKit backend. Unfortunately, the
html backend is missing a few features that flutter_svg depends on.
Yes but we can't really force de mobile browsers to use CanvasKit, as it
is way more heavy.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-774478384,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABD7O4EBM6EMWZ5CMB6NAQDS5VAOTANCNFSM4B3FXMMQ
.

can't we just add an kIsWeb switch?

Mobile browsers are Web as well so no. Anyways it is unrelated, you can compile your app to use CanvasKit on web always, but as I said, it is way more heavy.

It should be possible to fix the missing feature

@ohir commented on Apr 24, 2018:

There is a compact format for subset of svg coined for Shiny (Go desktop framework) by someone at the big G. Its binary representation and can bring default Android launcher icon size under 100 bytes.

Hi. I'm the "someone at the big G" who invented Shiny and its vector file format, IconVG. I've only just seen this issue.
IconVG is a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.
IconVG is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to "SVG Tiny", it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc.
Quoting myself from the IconVG announcement:
"The SVG spec prints as 400 pages, not including the XML, CSS or XSLT specifications. [The IconVG godoc.org page, which includes the file format specification, prints as 26 pages]...
The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."

Some examples (in binary IconVG, "byte-code disassembled" (human-readable) IconVG, SVG and PNG) are at https://github.com/golang/exp/tree/master/shiny/iconvg/testdata

I'm happy to work with Flutter folks if they're interested in integrating it. Right now, I only know of a Go implementation, but I can write a C/C++ one if needed. The Go package (decoder, encoder and basic tests) weighs under 5k lines of code.

That seems like a match made in heaven.

@Hixie ping!

The Material Design icon set... consists of 961 vector icons. As SVG files, this totals 312,887 bytes. As 24 * 24 pixel PNGs, 190,840 bytes. As 48 * 48 pixel PNGs, 318,219 bytes. As IconVGs, 122,012 bytes."

Hi. I'm the "someone at the big G" who invented Shiny and its vector graphics file format, IconVG. [...] I'm happy to work with Flutter folks if they're interested in integrating it. Right now, I only know of a Go implementation, but I can write a C/C++ one if needed. [@ nigeltao]

[cc: @dnfield]

IconVG looks interesting. I'm still working on determining what feature set we need to address here, and I suspect that our goals may differ slightly from IconVG's (e.g. animation and text, and batch-loading data for shader-based implementations are things I'm currently thinking we should support, which aren't supported by IconVG as far as I can tell), but to the extent that we can work together, I'm happy to do so.

IconVG is an extensible format, and animation was always possibly part of a version 0.2. I just haven't had the need for it yet.
Similarly, icon collections and sharing common data across multiple icons could be in a future version. I'm not sure if that's what you mean by batch data.
For shaders, https://github.com/reactivego/ivg is apparently a GPU-based IconVG renderer but I haven't looked deeply into it.
Text is trickier, if it requires pulling in a full OpenType rasterization and text shaping engine as dependencies, and some mechanism of embedding fonts (not just their 'flattened' vectors of the glyphs in use). One not-immediately-obvious design principle is that IconVG is not an authoring format, only a presentation format.
The analogy is that an artist can use Photoshop (and its PSD file format) with all its rich authoring, layering and typesetting tools, but will export to PNG for use in their app. Fluttter only has to ship a PNG decoder, not a PSD decoder. Similarly, artists could work in Illustrator (AI files) or Inkscape (SVG files) and export to IconVG. The authoring tools certainly need to know text, but the IconVG renderer doesn't necessarily need to.
Anyway, the more you let me know about your required feature set, the more I can say whether IconVG is (or can be) appropriate.

@Hixie

e.g. animation and text, and batch

I doubt that text should be supported in vector format meant for the app assets — as practically all contemporary apps must support i18n. This is supported by Flutter on the widget level. Any text that is used for symbolic purposes within drawings will be turned to vectors by designer anyway. Dealing with text would add much bloat for no apparent gain. IMO, it would be much more useful to support addressable layers within. Eg, for having programttically composable variants (think added star badge or similar).

programttically composable variants (think added star badge or similar)

Yeah, an IconVG graphic (see this example disassembly) consists of:

a magic identifier,
one or more metadata bytes then
a sequence of variable length instructions for a virtual machine.

Adding a star badge should be as easy as concatenating the instructions, possibly also inserting a "re-initialize the icon-global state" op to e.g. reset the color registers to their initial values.
As I said, icon collections and sharing common data across multiple icons could be in a future version. This could mean that a star badge would be like a Combining Diacritical Mark in a font, where 'a' and 'acute' are separate glyphs (icons) that are combined to make 'a-acute'.

IMO, it would be much more useful to support addressable layers within.

Addressable layers would also allow animation logic to be externalized, which I think would benefit use cases where vector animations are meant to coordinate with other motion in an application.

Isn't that basically Rive?

Isn't that basically Rive?

Well i believe rive had to find some workarounds in the form of the rive package (much like flutter_svg) to make that work because the discusion about a fully engine integrated drawable format wasn't resolved  at the time.

5 years past.. Are there any news about support for SVG in flutter? I hope that they will make support from the box, not "Package". Besides of it, it is very difficult to add some custom font icons in project without using of standart material design icons.

@Mickey-A-Mouse This issue is specifically not about SVG (see the title); if you have SVG-specific needs, please file a separate issue.

Please correct me, if I'm wrong. The current standing with vector image formats in Flutter is the following:

Out of the box only Fonts are supported and allow drawing vector images. There're two problems with this format: only single or dual tone images can be displayed; one needs extra processing of input files (most likely SVGs) via 3rd party tool to prepare a font and also Dart classes (there're plug-ins on pub.dev)
There're plugins on pub.dev which can render static svgs, though there can be issue with stability(I believe flutter_svg didn't work with canvaskit) and platform support (not all plug-ins offer all 6 platforms), additionally many plug-ins are not updated to null-safety.

Long story short, want vector images - use Fonts or pub.dev plugins.
Besides, it is not quite clear what this ticket offers to do. Create own Flutter vector image format native to the platform and tooling to convert to it? Or do limited support of SVG or other vector image format that allows render the image (and bypass complicated stuff such as animations, scripting, HTML embedding etc.)?
Btw, what are other wide spread vector image formats besides SVG.

is not quite clear what this ticket offers to do. Create own Flutter vector image format native to the platform and tooling to convert to it?

This issue calls for exposing Skia's (flutter drawing engine, vector one) primitives via a simple compact binary format for the purpose of embedding scalable image assets. Once format (eg. proposed in 2016 IconVG) will be estabilished and supported by the engine then conversion tools may emerge from the community.

Or do limited support of SVG or other vector image format to allow rendering of known types of vector images

SVG is supported via the pub package.

SVG is supported via the pub package.

@ohir unfortunately using flutter_svg in production with lots of dynamic images is not very reliable. We often run into issues where some features of SVG aren't supported resulting in broken SVGs.
We even built workarounds where we send the SVG to a NodeJS server, convert the SVG to a PNG with the help of puppeteer to reliably display SVGs without any UI bugs.
However, I deeply appreciate all the work @dnfield puts into this package. 💪

The reason why the team is not supporting SVG might because that the full feature of SVG is good enough to support a UI rendering directly, rather than just imaging. But the design of flutter is too different than SVG, specially on web.

I am also confused by the title change

@lukepighetti It's quite obvious that the team is not going to support SVG, but will provide support for vector images.

I don't really get why we need to design a new vector file format. Surely there must be something out there that meets our needs?

@lukepighetti I don't think you're missing the point, this issue reeks of NIH syndrome. SVG is probably the most widely accepted and supported vector format in existence. Lacking support for it in a framework intended for mobile app development is arguably worse than lacking support for JPEG.

NIH syndrome doesn't even explain it, since we have https://github.com/google/iconvg as a contender, which is in house goog and appears to have SVG translators already available https://github.com/google/iconvg

My prediction is this is going to get kicked out for months/years and everyone will move on and @dnfield will prop vector graphics on the platform up with flutter_svg

@lukepighetti

I don't really get why we need to design a new vector file format. Surely there must be something out there that meets our needs?

I do not know why it's called "new" now, but the engineering constraints demand compact binary format. Initially this issue was about exposing skia's vector drawing capabilities without bloating the engine, ie (as I envisioned a couple years ago) on the engine side a small rudimentary interpreter of bytecode should be enough.

my prediction is this is going to get kicked out for months/years

Sad, but apparently true. 64 months passed, and counting. Probably we do not know of some internal policy issue forbidding flutter team from adding fast drawing capabilities to the static assets domain.
@rmtmckenzie

if a completely new vector format on its own is going to help with

Both SVG and the subsed called VectorDravable are XML based. We need not to parse ML trees in the engine. That's left for converter tools.

We wouldn't want to expose the internal Skia format because that format changes all the time. If we're going to expose something that is longer-lived than that, then we need to design it very carefully. I have a work-in-progress document that goes through the requirements we'd need to do that, I should make it available sometime.

Is IconVG still a candidate or has some divergent design goal with it been identified?

I think supporting IconVG for Flutter is a great idea. I'm not quite sure it would resolve this issue, due to the narrowness of its scope. Another current challenge would be writing a backend for it that doesn't depend on the Go runtime. Another comparison to consider when looking at how it would do rendering the Material Design icons is against the fonts we use to ship them, that is really how Flutter apps consume Material Design icons (not as SVGs). It would probably be possible to support IconVG as part of flutter_svg, or using the same architecture as flutter_svg - i.e. without any changes to the engine.
The basic idea of this issue is that existing vector graphic formats (PDF, PostScript, SVG as front-runners) don't quite measure up to what we want. They're either overly-complex and expanisve (PDF includes a 3d modeling API; SVG includes basically the entire CSS spec and JavaScript; PostScript is also a programming language). You end up wanting at best a subset of their functionality, even then you end up with baggage. flutter_svg only supports a narrow subset of the spec, but still needs a full XML parser. I made some choices to make sure we wouldn't need a full in-memory DOM for it, but that still means it's really hard to support some features people want. On top of that, there's now SVG 2.0, which isn't widely adopted, and has added new features without resolving some of these issues - which perhaps aren't issues it even cares to resolve.
So we have choices to make between some tactical solutions (limited SVG support, perhaps full IconVG support). But this issue is really about coming up with a longer-term solution, which involves some hard work and planning.
Flutter may also still want something even more immediate, e.g. something that can basically dump out shaders and/or pipeline state information. For instance, it'd be fantastic to be able to just use Chrome to render the SVG and gather some platform independent shader/state information from that and have Flutter render that.

Is the point of this issue to create a brand new vector format that solved the issues of existing formats which could then be used outside of Flutter?
If not, can we make a binary format that maps to imperative CustomPainter code?

Is the point of this issue to create a brand new vector format that solves the issues of existing formats which could then be used outside of Flutter?

Yes.

can we make a binary format that maps to imperative CustomPainter code?

Certainly; that would be best done as a package and not as part of the core framework or engine (same as flutter_svg).

If the goal of this issue is to solve vector graphics for the world, perhaps it deserves a larger home than a single issue on flutter/flutter repo?

In due course, yup.

I think supporting IconVG for Flutter is a great idea. I'm not quite sure it would resolve this issue, due to the narrowness of its scope. Another current challenge would be writing a backend for it that doesn't depend on the Go runtime.

Some of you might already have noticed IconVG's new home: https://github.com/google/iconvg
There is now an IconVG decoder written in C. Pluggable rasterizer back-ends include Cairo and Skia. It's about 3.6k lines of code. In comparison, e.g. librsvg is about 35.9k lines or code, not counting its numerous dependencies.
That C library is hot off the presses, not even a version 0.1 yet, but it should be substantial enough for anyone here to play with it if motivated.
There's also a couple of issues filed for discussing IconVG animation and some consequent implications for the IconVG wire format.

just FYI, there is interesting SVG rasterizer https://github.com/RazrFalcon/resvg which preprocess SVG into simplified Micro SVG form https://github.com/RazrFalcon/resvg/tree/master/usvg

That C library is hot off the presses, not even a version 0.1 yet, but it should be substantial enough for anyone here to play with it if motivated.

For anyone playing with it, please sync past https://github.com/google/iconvg/commit/09a6ed3813202ef0601e1d222f7f8c80247fcfd6 (pushed a few hours ago) to pick up a bug fix in the "convert IconVG to PNG" program. How embarrassing!

Another comparison to consider when looking at how it would do rendering the Material Design icons is against the fonts we use to ship them, that is really how Flutter apps consume Material Design icons (not as SVGs).

I forgot to mention... IIUC such icon fonts can typically only represent single color icons (e.g. black, with alpha). This works for the Material Design icons, but in general, vector graphics can obviously be multi-colored and IconVG can represent that.
OpenType fonts can admittedly represent colorful emoji, but there are multiple ways to do this (at the file format level) and sometimes this is done by embedding SVG files in the TTF/OTF file, which obviously doesn't help here.
Such fonts could use the COLR/CPAL tables instead, I guess. Freetype only started supporting these tables in version 2.10 (released March 2019).

I put together some notes on this topic here: flutter.dev/go/vector-graphics

flutter.dev/go/vector-graphics has a section at the bottom with a proposal for a new format. There's some known issues that early reviewers have reported, but they're mostly minor so far; I'd be very interested in particular in feedback from people who see this format proposal as a non-starter or who see major failings with the proposal as it stands.

has a section at the bottom with a proposal for a new format.

The table of contents confuses me. Do you mean "A fixed-alignment binary format"? @Hixie If so, I guess I would make the headline larger and actually state that it is the proposal for a new format 👍
And since the document is too long for me to find where the comment would be suited, I want to ask a question here @Hixie:

Does this proposal have in mind that the number one use case is using existing vector graphics?
Will it be supported as an option for export by the tools used to create vector graphics (e.g. Adobe Illustrator)?
Will it have first-party support for converting from SVG and other vector formats?

Yeah, it's the "A fixed-alignment binary format" section. It's mostly intended to provoke discussion currently, not implementations, which is why I'm not describing it as a formal proposal.

Does this proposal have in mind that the number one use case is using existing vector graphics?

Yes.

Will it be supported as an option for export by the tools used to create vector graphics (e.g. Adobe Illustrator)?
Will it have first-party support for converting from SVG and other vector formats?

Right now it's just a strawman proposal, in its current form it won't even be supported by Flutter, let alone anyone else. :-)
But whatever actual proposals come out of this, whether they are almost identical to the current strawman proposal or whether they are completely different, support as an export format from other tools is a necessary step to deploying a new format, so yes, I imagine we would definitely find a way to export from Adobe Illustrator and other tools. Conversion from SVG is tricky for all the same reasons that implementing SVG is tricky (e.g. I wouldn't expect scripted SVG to ever be perfectly exported to another format, since that's mathematically impossible to implement in the general case), but again, one would definitely want to make tools that support that kind of thing. The tool I wrote to experiment with WVG (the format in the doc above) supports a subset of SVG path syntax, which allowed me to test some images with it. (There's a link to them in the doc.)

Thanks a lot @Hixie ❤  That does sound a like like what I wanted to hear 🙂

Conversion from SVG is tricky for all the same reasons that implementing SVG is tricky (e.g. I wouldn't expect scripted SVG to ever be perfectly exported to another format, since that's mathematically impossible to implement in the general case)

I am of course aware that SVG is tricky because the format itself is not sufficiently standardized. The reason I brought it up is because I feel that this is one of the requirements to make Flutter Web feel web-native. You see, in any HTML web app, you can simply plug-in any SVG file and it just works. Iirc, Chrome has some of the best compatibility when it comes to displaying SVGs.
And since it is such a widely used format, I really do feel that having this same plugging in any SVG file just works is a big opportunity for Flutter Web.
For context, efforts like flutter_svg are nice, but if I am really honest, they are not sufficient. What we end up doing is converting all SVG files to a raster format when using Flutter because almost all SVG files have some kind of incompatibility with flutter_svg and that is why I think this is a big lever.

So the reason I mentioned SVG: I think it is a key to Flutter Web.
And your strawman proposal gives me a positive feeling (for Flutter as a whole) 🚀

If we come up with a new standard here we'd want to work with the browser vendors also to implement it there too, so you'd be able to use the same images in Flutter and on the web just like you can with PNGs.

Could it also be possible for the Flutter web HTML renderer to handle $newStandard -> SVG?

In general I suspect any vector graphics format could be converted to SVG, since SVG is very expressive.

First of all: thank you, @Hixie for coming up with more general, even if sketchy, proposal.

see major failings with the proposal as it stands

I see no apparent failings, with minor one of it being much aware about current GPU capabilities. Though, thinking future, next format would be for either holographic, or for direct silicon-protein interfaces ;) So... just keep working on this one, please.

@creativecreatorormaybenot

in any HTML web app, you can simply plug-in any SVG file and it just works. Iirc,

(Any SVG) "just works" if displayed in Chrome. And it is enough fast on the overpowered machine with hyperpowered GPU. "Any" SVG to be displayed with desktop's older browser, or on low end phone/tablet needs much massaging before deployment.
That said, as discussed format addresses the very bottleneck problems of the current "standard", and it will see first implementation targetted at Skia (that runs behind Chrome and Flutter), and it will carry statically precomposed scene graph(s) — we may expect both decent sizes and the good rendering speeds. Huge win over SVG.

I think we all agree that SVG is a terrible format.

I don't agree with that.

me too :D
On Sat, Jul 17, 2021 at 11:51 PM Jonah Greenthal @.***>
wrote:

I don't agree with that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/flutter/flutter/issues/1831#issuecomment-881970545,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA5YN5IUNXRXZQPPOQCIH23TYICPTANCNFSM4B3FXMMQ
.

I would love to see how this bare-bones vector format compares in performance against the similar bare-bones implementation of it's equivalent SVG feature set. Basically the tiniest of features of the SVG Tiny 1.1 spec, let's call it 'SVG Atom-Tiny 1.1'.

WVG looks super interesting, especially given that ideally it could be used in Flutter (which of course I'm a fan of) but in browsers as well. SVG is great but imo the spec surface area is so large I've even found browser bugs with SVG implementations before.
Reading https://flutter.dev/go/vector-graphics I'd almost wonder if the human readable format should be JSON based?
Excited to see what this turns into! 😃

FWIW, I took a swing at the SVG TIny features (plus a bit of SVG 1.1 not in Tiny) that are worth supporting.  Here's my current list, taken from the readme of my jovial_svg library on pub.dev.
One thing I haven't thought about is making some sort of DOM-like API to manipulate the resulting asset programmatically (e.g. for animation).
Supported SVG Profile
SVG profile notes:

SVG paths and transforms are of course supported.
The use element is supported (including forward references).
Stroke modifiers like stroke-linecap, stroke-linejoin and
stroke-miterlimit are supported.
The stroke-dasharray and stroke-dashoffset attributes are
supported (cf. Tiny s. 11.4).
Gradients are supported, and additionally support xlink:href attributes
to other gradients, and gradientTransform attributes from SVG 1.1.
Text elements are supported.
Embedded images are supported.
Object/group opacity is supported -- cf. SVG 1.1 s. 14.5.  It was
eliminated from SVG Tiny 1.2.
As per the Tiny spec s. 6.2, full CSS is not supported.  However, the
style= attribute is supported as a way of specifying presentation
attributes.
Non-scaling stroke is not supported (not in SVG 1.1; cf. Tiny 11.5)
Constrained transformations are not supported (not in SVG 1.1;
cf. Tiny 7.7)
A DOM and other features related to animation are not supported.
Conditional processing (Tiny s. 5.8) is not supported
The clipPath SVG element is not supported (cf. SVG 1.1 14.3.5).  It
is not defined for SVG Tiny 1.2.  The more restricted Android Vector
Drawable clipPath is supported for AVD files, however.
Filter effects (SVG s. 15) are not supported.  They are not a part
of SVG Tiny 1.2.
Text restrictions:

Embedded fonts are not supported.  However, the font-family attribute
is used when selecting a font, and fonts can be included in an
application that uses this library.  For example, the demo program
includes the ROLLERBALL 1975 font.
textArea is not supported (not in SVG 1.1).
font-variant (small-caps) is not supported.
rotate is not supported (but normal transformations, including
rotation, apply to text elements).
Bi-directional text is not supported

Quick status update: I'm afraid there hasn't been any progress since last summer's updates. The next step is to experiment with implementing the proposal using shaders, to see how practical the suggested approach actually is. If anyone is interested in trying that out please don't hesitate to reach out to me<EMAIL_ADDRESS>or if you're on our Discord just ping me in the #hackers channel). It's unlikely that anyone on the Flutter team will have the bandwidth to work on this any time soon because our shader experts are focused on the more important task of addressing jank issues.
There have been some other proposals from other folks in the meantime; IconVG has had a major update recently and TinyVG was recently proposed. These formats solve different problems than the problems we are primarily worried about here, but are interesting nonetheless.

TinyVG looks promising. It is not part of your write up, so...

What problem does it solves that is different from the ones you wish to solve ?
Are you active in one of those repositories to see if the specifications can align with the flutter team ?
Is there anything that the team can do to allow easier integration with those formats by the community ? I'm down to help.
Since doing a new specification is too much work it might be a good idea to implement the existing ones in the meantime, ain't it better than nothing ?

It's just that, when this issue lasted through 3 US presidents so far, Obama, Trump and now Biden, soon enough it will outlive the democratic system.

TinyVG post-dates the work on that document, yeah. It seems to be about creating small files. This isn't really a problem that I think needs solving (gzipped SVG files are sufficiently small for most purposes), the problem that seems valuable to solve is rendering performance (the doc goes into more detail about the order of priorities).
These formats (including SVG) are already implementable pretty reasonably today, using techniques similar to flutter_svg. I did a demo of WVG that way too. This is just driving a canvas, basically (at the core, Flutter is just a way to drive a canvas). So if you are interested in implementing them, please don't hesitate to create packages along those lines. (For IconVG I did a Flutter implementation of the earlier version of the format, it's in the IconVG repo IIRC.)

Whatever new format is decided, I think us devs will need a reliable way to export a SVG in to this new format. A Figma plugin can help with conversion maybe? Or a third party tool.
It has been nearly 6 years and Flutter has evolved a lot in terms of performance. Are we still thinking that Flutter can not handle the full SVG specifications?

@aytunch I'm curious as well. I think that even in the original issue statement, there should be room for reconsideration at this point.
"We don't want full SVG support" seems reasonable to me, because full support is a tall order. However, with all due respect to the brilliant people behind Flutter, if that means zero work on improving the SVG experience, this whole thing reads like Waiting for Godot.

I am 100% certain that Flutter cannot handle the full SVG specification. In fact, on low end devices, Flutter will have a semi-challenging time handling even subsets of the specification, because SVG lets you do really dumb things and editors find interesting ways to do those dumb things, and existing optimization tools tend to focus on the wrong things (typically binary size of the encoded SVG rather than render complexity). On the web this isn't quite as big a deal because everything around you is so slow that SVG performance isn't as noticable. On Flutter running on a low end embedded device where you want to render this thing in real time at 60-120fps it matters a lot.
IconVG and TinyVG are interesting, and should be fairly simple to implement for Flutter if people want that. IMHO they do not quite hit the sweet spot of supporting enough features compared to static SVG, and they also have heavily optimized for binary size rather than for encouraging better render composition for dynamic online rendering.
I think ideally, we'd have a format that supports the following:

A static format that does not support variables or animations, and potentially does not support text.
A dynamic format that supports variables, animations, and text.

Both formats would be constructed with the following in mind:

Binary size matters, but not as much as people seem to think. When choosing between binary size and render complexity, optimize for less render complexity (but this will also typically reduce binary size as a side effect).
Render complexity matters a whole lot more. Offline tooling is necessary to both optimize and score render complexity. Designers and programmers need to undertand how expensive it will be to render their desired graphic on target hardware.
Render complexity is less about "can quickly translate to GPU instructions" and more about "Can quickly translate to GPU instructions that the GPU can process quickly."

To this end:

The format should discourage and preprocess away anything that requires targetting a new bitmap during the render pass. E.g. opacity applied to groups, color filtering applied to groups, masking operations.
The format should discourage/avoid real time overdraw.
The format should discourage expressing the same vectors differently over and over again - e.g. the same path drawn with different translations should be expressed once, and if a design tool messed this up it should be processed away at build time.

And yes, ideally the format would be able to render 100% of what Chrome can render in an SVG in a single frame.

In fact, SVG in Chrome is more than a graphic format to represent a vector image (both static and dynamic). SVG inside WebKit can be a foundation of GUI elements, thus it's possible to implement a fully functional modern Web GUI with SVG+CSS+JS, and SVG will be serving as the low level drawing primitives and interactive element supports. Which is a fully alternative to the HTML5+CSS+JS approach for web apps.
The question I wish to introduce is:

Should Flutter SVG support interactive vector graphics?

The decision of this question can lead to two braining directions:

Flutter SVG as a vector image representation for lost-less scalable graphics elements.
Flutter SVG as a applet container serving more than animations, but also user interactive graphics elements.

Most talks in this thread before this is about the vector image part of SVG. But the most exciting approach is the transparent integration of SVG and Dart/Flutter when it's going to be an applet container. This is will enable designer to do more jobs for user interface with a modern SVG editor thus release more work from programmer.

SVG is explicitly out of scope for this bug; for SVG discussions I encourage you to file separate bugs.
https://flutter.dev/go/vector-graphics answers most of the questions above, FWIW. I would encourage people to read that paper and comment there if it doesn't answer your questions about what this issue is about.

Issue #15501 was closed and locked automatically due to inactivity, and after that, a reference to this issue was included. I suspect that most comments in this thread are a result of that reference. Someone not really paying too much attention to the topic might expect this thread to be about one of the following:

This is the place to discuss the general lack of SVG support in Flutter
This is the place to discuss the expected level of SVG support in Flutter

If someone wants to make an issue about adding SVG support to Flutter, can they just create a new GitHub issue about that?
Additionally, I think a lot of people have commented on this issue to question the validity of the plan to design a completely new vector format specifically designed with Flutter's technical capabilities in mind. I don't believe these comments have been met with the appropriate description of exactly what the issues are.
It has now been more than six years since the issue was created, and the latest progress I've seen is the Google Docs document describing a proposal, with a few comments from very few different developers. That document is way too technical for 99.99% of the people reading this issue, and the discussion seems to have stagnated. I'm not surprised, because as an outsider, there's still no obvious path forward here. Who is in charge of making this happen? How many people are actively working on making it a reality?
It's obviously a huge hill to climb, and the incline is steep here. Not many people in the world can realistically take on the task and complete it. How long is the Flutter dev team willing to wait on this idea becoming reality? A decade? Until the end of time? I'm not being sarcastic, I'm truly interested in knowing what's going on with the new vector graphics format. Flutter 3 was released recently. Is the goal to have completed this issue by Flutter 4? Is there discussion internally within the Flutter dev team about this? I think an update is due here.
To be clear, this is not intended as criticism of the work put into the Flutter project, these are genuine questions and concerns of mine regarding the future.

https://pub.dev/packages/flutter_svg is still the most common/popular way to render SVGs using Flutter. It works reasonably well, but has some performance issues that I have not been able to overcome and that I think are inherent to a combination of the SVG specification, XML, and limitations Flutter currently has around dynamic shader compilation.
There are at least three other SVG implementations for Flutter

https://pub.dev/packages/jovial_svg
https://pub.dev/packages/rive
https://fluttershapemaker.com/

In addition, @jonahwilliams and I are working a new package called vector_graphics that more efficiently compiles SVGs to a binary format while still supporitng a larger portion of the SVG specification than the current offerings do. This is something of a halfway step between what you're asking for (better SVG support) and what this issue is actually about (a better vector graphics format). vector_graphics is intentionally trying to avoid creating a new format for the time being. At some point, it may be able to output to something like the document linked for the proposed new specification. The new package already supports most of what flutter_svg does and a little more, but it is not quite ready for pub.dev and is still missing at least a couple features that flutter_svg has (notably, image support).
This issue, as has been mentioned before, does not aim to be something that is simple of quick to implement. It's not clear to me if or when this will ever get implemented. If it does get implemented, I expect it won't really be meaningfully implemented for at least another year.

Following to see if support is added for this

@dnfield Hi,

but has some performance issues that I have not been able to overcome and that I think are inherent to a combination of the SVG specification, XML, and limitations Flutter currently has around dynamic shader compilation.

Would Impeller be of any help with either flutter_svg or the vector_graphics that you guys are working on?
Thanks

I'm going to close this issue. While we may follow up on this topic one day, it is not currently part of our medium term roadmap, as it will be a long time before low-end GPUs are ready for the kind of evolution we could do here that would be a significantly improvement.
For people interested in following along, I recommend checking https://flutter.dev/go/vector-graphics occasionally, as that is where any further updates are likely to be posted.

@Hixie does it make sense to add a "Last Updated" to that document, as we as "Commentators" can't see the version history.

The document is quite long to know when something has changed there.

There's a date at the very top that gets updated whenever significant changes are made.


Improve "artifact repo not configured" error message

Summary
When you run a workflow which uses artifacts, but you do not have an artifact repo configured (like with the default install.yaml), the workflow will fail with key unsupported: cannot get key for artifact location, because it is invalid.
This message doesn't effectively convey the real problem: the user needs an artifact repo. I know of at least two goose chases caused by the misleading error message.
To reproduce:

install default install.yaml
run the artifact passing example

Message from the maintainers:
Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

maybe we should like to help?

Yeah I think that would be great. A link to the artifact repo config doc I guess.