plenty of other problems

- They often render differently in different browsers and other renderers. It's very frustrating to get consistent results (like a PDF). In complex diagrams I'd say it's basically impossible

- Renderers that are fast usually lack many features

- Nobody other than the browser seems to actually have all the features?

- You can link an SVG within an SVG (to make a lightweight composite image). But if you have two levels of indirection then all renderers I've tried will refuse to render the SVG

- Inkscape is basically the only good editor on Linux and it easily runs out of memory and crashes for complex images

- Complex SVGs eat all your RAM in Chromium (only marginally better in Firefox)

- Basic things like arrows from Inkscape will not render anywhere else

I still use SVGs all the time, b/c there are no good alternatives, but it's a crappy standard and I try to keep all my images/diagrams extremely simple

> and has text converted to curves.

But this then loses the ability to select it as text—which, at least in Safari, is present with an SVG <text> element.

So either way you don't get full functionality.

Safari supports base64-embedding font files in a <style>’s @font-face {} (iirc it's something like `@font-face { src: url('data:application/x-font-woff;charset=utf-8;base64,...'); }`) that can then be referenced as normal throughout the SVG. I don't recommend this though, nobody wants to deal with 500KB SVGs.

The idea was that you can embed only the glyphs used in a text. For example, instead of embedding thousands of existing Chinese characters, embed only 20 of them. Embedding is necessary anyway because otherwise you cannot guarantee that your image will be displayed correctly on the other machine.

Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.

> Also, allowing CSS inside SVG is not a great idea because the SVG renderer needs to include full CSS parser, and for example, will Inkscape work correctly when there is embedded CSS with base64 fonts? Not sure.

For better or worse, CSS parsing and WOFF support are both mandatory in SVG 2.[0][1] Time will tell whether this makes it a dead spec!

[0] https://www.w3.org/TR/SVG2/styling.html#StylingUsingCSS

[1] https://www.w3.org/TR/SVG2/text.html#FontsGlyphs

That's how OpenCL died. They made difficult to implement features mandatory.

You can also point to font files with @font-face. I use a small custom font that's only 16 KB. Although, when opening the file locally, you have to first disable local file restrictions in safari's settings before it works...

  <defs>
  <style type="text/css">
  @font-face {
  font-family: 'A-font';
  src: url('A-font.woff') format('woff');
  font-weight: normal;
  font-style: normal; }
  </style>
  </defs>

So if you save the SVG image, it won't display without Internet connection. Not great.

I don't think that helps with embedding fonts.

> - cannot wrap text

This is possible, but only in the stupid way of using a `<foreignObject>` to embed HTML in your SVG (which obviously only works if your SVG renderer also supports at least a subset of HTML). SVG 2 fixes this by adding support for `inline-size`[0], so now UAs just need to… support that.

> - cannot embed font glyphs - your SVG might be unreadable if the user doesn't have the font installed. You can convert letters to curves, but then you won't be able to select and edit text. It's such an obvious problem, yet nobody thought of it, how?

Somebody did think of it. SVG 1.1 added the `<font>` element[1]; SVG 2.0 replaced this with mandatory WOFF support.[2] A WOFF is both subsettable and embeddable using a data URI, and is supported by all the browser UAs already, so it’s obvious why this was changed, but embeddable SVG fonts have existed for a long time (I don’t know why/how they got memory holed).

> - browsers do not publish, which version and features they support

It should be possible to use CSS `@supports` for most of this and hide/show parts of the SVG accordingly in most places.[3] The SVG spec itself includes its own mechanism for feature detection[4], but since it is for “capabilities within a user agent that go beyond the feature set defined in this specification”, it’s essentially worthless.

There are obvious unsolved problems with SVG text, but they are more subtle. For example, many things one might want to render with SVG (like graphs) make more sense with an origin at the bottom-left. This is trivial using a global transform `scaleY(-100%)`, except for text. There is no “baseline” transform origin, nor any CSS unit for the ascent or descent of the line box, nor any supported `vector-effect` keyword to make the transformation apply only to the position and not the rendering. So unless the text is all the same size, and/or you know the font metrics in advance and can hard-code the correct translations, it is impossible to do the trivial thing.

There are other issues in a similar vein where scaling control is just ludicrously inadequate. Would you like to have a shape with a pattern fill that dynamically resizes itself to fill the SVG, but doesn’t distort the pattern, like how HTML elements and CSS `background` work? Good luck! (It’s possible, but much like the situation with text wrapping, requires egregious hacks.)

Some of the new `vector-effect` keywords in SVG 2 seem like they could address at least some of this, but those are “at risk” features which are not supported by UAs and may still be dropped from the final SVG 2 spec.

[0] https://www.w3.org/TR/SVG2/text.html#InlineSizeProperty

[1] https://www.w3.org/TR/SVG11/fonts.html

[2] https://www.w3.org/TR/SVG2/changes.html#fonts

[3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...

[4] https://www.w3.org/TR/SVG2/struct.html#ConditionalProcessing...

Interesting, I stumbled upon SVG fonts only as a format for webfonts in CSS.