Text width calculation

[demensky]

Problem

Having text in SVG is never easy. I found a few problems with text width calculation:

Possible Solution

There is an opentype.js library. It allows you to parse font files and do various manipulations with them. One of them is the calculation of the width of the text.

I propose to calculate the size of the text using this library and adjust the size of the elements.

Also! This may help to remove the <foreignObject /> hack.

[timdp]

The obvious workaround is to assign a width that will accommodate longer strings, but it'd of course be nicer if automatically stretching the container were an option.

Like you said, SVG is a bit limited when it comes to flowing text, and that's also why the foreignObject workaround exists. A future version of SVG might improve things but I'm not holding my breath.

The challenge with using a library to compute the bounding box is that it'll produce platform-specific values. It's a little implicit, but Swirly actually lets you specifiy multiple font families, so that the renderer can pick the first matching one. And that in turn of course depends on which ones are available on the device. (Also, different renderers might render the same font slightly differently.)

Naturally, this only applies when rendering the SVG from source. When rasterizing to PNG, it would be consistent - as long as the same font file is used in both cases.

Nevertheless, you could argue that some heuristic that stretches the container accordingly would be an improvement over a statically defined size, so Swirly could at least give you the option, even if the result isn't 100% accurate in all cases. In a way, that's not too dissimilar from the foreignObject approach, which also doesn't work on all platforms. I'll give it some more thought.

[demensky]

I'll try to make a prototype to see how feasible it is. I will also try to take into account the remark regarding the specific display of the font on different platforms, I think that Path.toPathData is suitable for this.

[demensky]

An early version of the prototype.

progress.webm

Implemented features:

1. Drawing text with <path />. No need to worry about the presence of the font.
2. Dynamic calculation of stream title width.
3. Dynamic calculation of operator width. <foreignObject /> is not used.
4. Lack of sub pixel coordinates. Clearer display.
5. Rendering without browser APIs. Can be easily run in Node.js.

The appearance is still dirty due to the fact that I have not yet implemented style support.

@timdp I want to know your opinion.

[demensky]

Example

• [x] complete & error now have the same radius as next. But complete & error become larger if next overlaps them. Just like here.
• [x] Built-in dark theme.

The parser is not yet able to handle such a case (or I did not understand how):

• [x] Has no restriction on nesting of streams. An example is below.
• [x] Nested streams in the operator. An example is below.

Diagram examples: