4 ms·

> How will this look in different browsers? Let's test! obviously different font widths for rendering of SVG text in different browsers/font stacks > That did

> How will this look in different browsers? Let's test! obviously different font widths for rendering of SVG text in different browsers/font stacks > That didn't go as expected. I thought that at least both files on my Linux machine look the same, but it seems like Firefox doesn't like the font-size specification, while Chrome and Edge do. I asked the Render-A-Webpage-As-An-SVG-framework guy about this last week. He claimed over multiple years he hasn't had a single report of broken text rendering from users of his framework. So what's the deal? Are OP and me the only devs who have ever hit up against this issue in practice?

deleted 5y ago
[deleted]
ikskuh 5y ago
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
- nine_k 5y ago
  This is a problem with any image format. Either you embed the font (or parts of it), or convert the text to curves.
- Shared404 5y ago
  > 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.
  - ikskuh 5y ago
    I wasn't talking about text in that case. Here's a screenshot of that image: https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a4e2.png https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...
    - Shared404 5y ago
      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.
templix 5y ago
> 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.
- nomel 5y ago
  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.
  - akyoan 5y ago
    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.
the_duke 5y ago
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.
chrismorgan 5y ago
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 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 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.
- jancsika 5y ago
  > 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?
  - RyanGoosling 5y ago
    Try any Bootstrap site

deleted 5y ago

[deleted]

ikskuh 5y ago

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

nine_k 5y ago
This is a problem with any image format. Either you embed the font (or parts of it), or convert the text to curves.
Shared404 5y ago
> 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.
- ikskuh 5y ago
  I wasn't talking about text in that case. Here's a screenshot of that image: https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a4e2.png https://mq32.de/public/9f3cd5eb7f310139cf8acdd61edb73080d26a...
  - Shared404 5y ago
    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.

templix 5y ago

> 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.

nomel 5y ago
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.
- akyoan 5y ago
  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.

the_duke 5y ago

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.

chrismorgan 5y ago

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 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 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.

jancsika 5y ago
> 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?
- RyanGoosling 5y ago
  Try any Bootstrap site