'text-anchor' and Arabic text

[RazrFalcon]

https://svgwg.org/svg2-draft/text.html#TextAnchoringProperties

<svg id="svg1" viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg"
     font-family="Arial" font-size="32">
    <path id="crosshair" d="M 20 100 L 180 100 M 100 20 L 100 180"
          stroke="gray" stroke-width="0.5"/>
    <text id="text1" x="100" y="60" text-anchor="end">
        مفتاح<tspan id="tspan2" x="100" y="100" text-anchor="middle">معايير</tspan>
        <tspan id="tspan1" x="100" y="140" text-anchor="start">الويب</tspan>
    </text>
    <rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>

Results:

As you can see, literally everyone is rendering it differently and I'm not sure which one is correct. I think the documentation needs some clarification. It mentions the direction property. But that's it.

[dirkschulze]

Same example in copepen: https://codepen.io/krit/pen/BvvbRM

[AmeliaBR]

As the spec is written, the start/end anchoring should only be affected by the direction property. With the default direction of ltr, start should be left and end should be right. The text itself can have bidirectional reordering inside it but the anchoring is based on the total length after reordering.

So, Firefox & librsvg would be the correct rendering (although the centering is a bit messed up in Firefox by whitespace getting tacked on to one end of each span).

There may be two things going on in @RazrFalcon's example:

• the browsers could be guessing direction based on content
• the browsers could be getting confused with direction switching for different <tspan> within the same <text>

I'd need to do a little exploring to figure out which is happening. Maybe a mix of both and just general bugginess.

Either way, some spec clarifications and lots of tests are probably required.

PS, another demo, without the tspans but with a bit of bidirectionality confusion:
https://oreillymedia.github.io/SVG_Text_Layout/ch07-rtl-vertical-files/text-direction.html

[fsoder]

Blink (Chrome) is know to have some issues with "multiple chunk BiDi/RTL", which I suspect is what being triggered here in the original TC.

[css-meeting-bot]

The SVG Working Group just discussed Text-anchor & RTL text, and agreed to the following:

• RESOLUTION: No major changes. Re-examine the spec text for clarifications after creating tests.

The full IRC log of that discussion

<AmeliaBR> Topic: Text-anchor & RTL text
<AmeliaBR> github: https://github.com//issues/628
<AmeliaBR> Dirk: Amelia, could you update?
<AmeliaBR> Amelia: So, clearly an interop problem. I think its mostly browser bugs, but probably could use some spec clarifications.
<AmeliaBR> Dirk: Are changes necessary for SVG 2.0
<AmeliaBR> Tav: needs better tests
<AmeliaBR> Amelia: Yes, either way tests are needed.
<AmeliaBR> Tav: for Inkscape, it looks like we're ignoring text-anchor on tspan. which is our bug.
<AmeliaBR> Dirk: Is there one rendering that is correct?
<AmeliaBR> Amelia: Looks like librsvg. But there are differences about glyph selection as well as alignment, not sure which version is correct.
<AmeliaBR> Dirk: Ok, so we need tests. Do we also need to change the spec.
<AmeliaBR> Amelia: That might be easier to decide as we write the tests. Need to make sure that every test is clearly supported by spec text.
<AmeliaBR> Dirk: Can we resolve then to revisit after testing?
<AmeliaBR> Amelia: To confirm, that means we are sticking with the main idea of the spec, that text-anchor is only based on explicitly declared `direction`, not on directionality of text characters?
<AmeliaBR> Tav: Yes, I don't think we want to change that now.
<AmeliaBR> RESOLUTION: No major changes. Re-examine the spec text for clarifications after creating tests.

[Tavmjong]

Tests at web-platform-tests/wpt#15118

[faceless2]

I don't think the libsvg rendering is completely correct, as the final glyph (U+062D, ح) on the top line isn't being shaped into a medial form - you can see that it is in Firefox (EDIT: note the "U+0645 م" on the next line should also be medial - but the examples above use Times New Roman, and I think the lack of medial shaping is particular to that font)

Shaping should really be applied across <tspan> boundaries, otherwise you can't change any properties (eg color) in the middle of a run of arabic without breaking text.

Shaping is applied across inline-element boundaries in CSS. The SVG2 spec says that <tspan> is analogous to an inline element, and is treated as one for white-space etc in SVG. I think it must be treated as one for shaping too.