What’s the deal? The font-size declaration in the style attribute was invalid, and Chromium allowed it, in direct contravention of both the SVG 1.1 and 2 specs, while Firefox disallowed it.

SVG 1.1 extends CSS 2’s font-size value to allow a unitless number on a font-size SVG attribute <https://www.w3.org/TR/SVG11/text.html#FontSizeProperty>, but when you specify it as a CSS style it must follow the CSS declaration form, which means that non-zero lengths must include a unit—<https://www.w3.org/TR/SVG11/styling.html#StyleAttribute> even explicitly mentions font-size as its example on this point.

SVG 2 removes the unitless number extension and defers to CSS Fonts Module Level 3 entirely for font-size, so that unitless non-zero numbers aren’t permitted even in a font-size attribute.

All up, it’s a bad example that doesn’t support the thesis in the slightest, because a rookie error was made. (There’s still something in the fact that such an error could be made so easily, but it’s not that big a deal, certainly not enough to suggest that text is unreliable beyond the fact that you don’t know what fonts are available.)

Text in SVG is just as good as text in HTML, except inasmuch as nothing implements runtime (font-dependent) line wrapping, so it’s kinda more like HTML with white-space:nowrap.

The interactions between presentation attributes and style properties are a bit fiddly and sometimes unclear. Take something like <rect x="2" y="2" width="calc(100% - 4px)" height="calc(100% - 4px)"/>; it’s not quite clear to me whether this is valid in SVG 1.1, though I think it should be in SVG 2. It works in both Firefox and Chromium, though Firefox logs a claim that it’s invalid in the dev tools. <rect style="x:2px;y:2px;width:calc(100% - 4px);height:calc(100% - 4px)"/>, on the other hand, is definitely fine.

> Text in SVG is just as good as text in HTML, except inasmuch as nothing implements runtime (font-dependent) line wrapping, so it’s kinda more like HTML with white-space:nowrap.

That's quite a caveat. How many current webpage designs depend on wrapping happening in exactly the same way across all browsers and device dimensions?

It's hardly a caveat for SVG - where you usually want total control over the placement of the text elements.

If you want it to look like a document with wrapping then use HTML for your text, not SVG

Try any Bootstrap site

That's a good question! I fell for this problem with text rendering once as the font i've used in a SVG wasn't installed on the target machine.

If i create a image, i want that image to look exactly the same on all machines. This is sadly not the fact for SVG :(

The W3C SVG example files contain a lot of these files that make every SVG renderer explode. There's images that don't render anywhere except inkscape

> There's images that don't render anywhere except inkscape

You just have to convert the text in the image to a path before using it wherever you plan on, just be sure to save the original for editing.

I wasn't talking about text in that case. Here's a screenshot of that image:

https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...

Huh. I'm afraid I don't know enough about Inkscape or the SVG specs to help with that, just enough to know it's a pain.

Off topic question for you though, that looks like probably i3 or dwm, did you make any modifications to Inkscape to make it more usable in a tiling wm, I always have to turn off tiling when I launch it.

This is a problem with any image format. Either you embed the font (or parts of it), or convert the text to curves.

> So what's the deal? Are OP and me the only devs who have ever hit up against this issue in practice?

The sad truth is that many issues go unreported because people are lazy and move on when they hit a roadblock.

Also, I've seen this problem reported more than a few times so you're not alone.

I've seen impressive amounts of code written to get around one line bugs that could be trivially fixed, if only reported. One time, the LOC of the workaround basically matched the LOC of the tool, with the workaround implementing a full parser to consume the output of the tool, rather than just directly loading the json the tool was consuming. I used to get frustrated at these things, but I've become a bit demented, reveling in the asinine, self inflicted, suffering that I sometimes witness. Watching people copy paste code changes, rather than using git, is an infinite source of entertainment that's seemingly impossible to stop.

The problem I encounter while developing occasionally is that I encounter a series of errors and in the end you stop wanting to report the 5th bug of the day and just want to fix things the best way you can. Sometimes that attempt goes sour, sometimes it gets me out of the problem in 5 minutes.

> if only reported

Reporting bugs can be super time consuming, especially if your project is large and the maintainer has a high bar for bug reports (e.g. "provide a codesandbox link"). I can't spend 20 minutes reporting a bug that will be auto-closed in 6 months when I can attempt fixing it instead, especially if I'm annoyed at the tool already. This used to happen a lot with browsers and nowadays it happens with build tools and libraries.

Nope, I also encountered text rendering issues with SVG.

I reckon devs will just drop SVG in favor of a PNG or re-export with text as paths instead of complaining somewhere.