The issue is much more complicated.

text-anchor, direction, and BIDI interact.

For the most part, SVG Translate should be able to ignore the problem by assuming that direction="ltr" and the .textContent will be strong LTR or strong RTL. In that case, BIDI reordering does the right thing. All text starts out LTR and has an appropriate text-anchor. If RTL text is encountered, Unicode BIDI embeds the RTL text into a separate RTL block within the initial LTR block. Doing nothing sort of works out. Things break down if some strong LTR text is encountered after the RTL: it will be placed to the right rather than the left of the RTL text block. But as long as the .textContent does not change direction, it will work out.

If one wants to do it right, then one must change both direction and text-anchor.

But that gets into trouble immediately. librsvg does not handle text-anchor correctly when when direction is RTL.

https://commons.wikimedia.org/wiki/File:SVG_Test_TextAlign.svg

The clever way to handle swapping text-anchor and direction is to put them in a CSS style element, but librsvg does not handle language selectors (e.g., :lang(ar)) or attribute selectors (e.g., [systemLanguage="ar"]).

To add more confusion, CSS text-align uses left or right in addition to (the experimental) start or end. IIRC, SVG 1.1 does not have that property.

The simple version is this issue is stalled until librsvg is fixed or WMF uses a different renderer.

Every time I hear a librsvg bug, I can't help but ask: "is it a Debian stable librsvg bug or an actual librsvg bug?" (urgh) And indeed, a quick test using rsvg-convert from libsrvg 2.50 shows the red and black text on the last line overlapping fine.

(Angry remarks about Debian "stale" and "please backport from testing" omitted.)

From [[ T271663#7050425 | Arthur2e5's comment ]], it sounds like the best way to handle this will be to wait for a librsvg upgrade and see if the problem is still there before starting work on it. Note that we have no timeline for (or control over) librsvg in Production, but we will keep an eye on this ticket, and revisit it if more information becomes available.

@JMcLeod_WMF: Does that imply that this task should have stalled status && its blocking subtask (via "Edit Related Tasks... 🡒 Edit Subtasks") should be set to T265549?