Confused about 'writing-mode' with 'direction'

[RazrFalcon]

https://www.w3.org/TR/SVG/text.html#WritingModeProperty
https://www.w3.org/TR/SVG/text.html#DirectionProperty

Afaiu, writing-mode was completely changed in SVG 2, but I think that the problem should persist. I'm not sure if there are any SVG 2 ready applications, so I cannot test this. That's why the example below is SVG 1.1 based.

<svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg" font-family="Arial" font-size="64">
    <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="150" writing-mode="tb" direction="rtl">Text</text>
    <rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>

As you can see, the results are pretty different. Which one is the correct one and why?

PS: is the SVG 1.1, the writing-mode property could have 6 different values. But according to the SVG 2 spec, there are actually only two of them: left-to-right and top-to-bottom. So in the SVG 1.1 I can treat lr-tb, rl and rl-tb as lr and tb-rl as tb and it should not technically affect anything?

[svgeesus]

Thanks for the nicely illustrated and documented issue!

SVG 2 defers to CSS Writing Modes 3, so please re-raise the issue over there

[fantasai]

This is an issue with how SVG defines the x and y attributes, not with how writing-mode works. Please re-open and resolve this in SVG2, there is nothing we can do to help in the CSS specs: the text is very obviously rendered in the correct manner and the only question is its placement in the coordinate space.

[svgeesus]

Thanks for the clarification, @fantasai

[svgeesus]

The relevant spec section is indeed too brief and does not clearly state the impact of the direction and writing-mode properties on the interpretation of the x and y attributes. It says:

Relationship to bidirectionality – Text is laid out in a two-step process, where any bidirectional text is first re-ordered into a left-to-right string, and then text layout occurs with the re-ordered text string.

[fantasai]

I think you need to fix #629 first, then clarify where the "alignment point" is in the inline axis (and make it clearly depend on 'text-anchor' and 'direction', see also #628), and specify that the alignment point is placed exactly at the specified x and y coordinate point.

[fantasai]

I believe that would result in Chrome's rendering in the screenshots above. Unsure about the exact x position since I can't see the font metrics... should be halfway between the ideo and idtp baselines.

[css-meeting-bot]

The SVG Working Group just discussed 'writing-mode' with 'direction'.

The full IRC log of that discussion

<AmeliaBR> Topic: 'writing-mode' with 'direction'
<AmeliaBR> github: https://github.com//issues/618
<chris> https://github.com//issues/629
<AmeliaBR> Chris: I'd initially thought this was a CSS issue, but fantasai threw it back to us, because this really comes down to x and y and text-anchor.
<AmeliaBR> Amelia: So the question is, if you have writing mode tb and direction rtl is start "top" or "bottom"?
<AmeliaBR> Chris: Yes, and as fantasai suggested there may be complications with issue 629
<AmeliaBR> Amelia: I'm not sure they are really dependent on each other. It's about alignment in the orthogonal direction.
<AmeliaBR> ... much of these may both be caused by SVG 1.1 spec text that needs to change to match changed property definitions in `writing-mode` and `dominant-baseline`.
<AmeliaBR> ... probably again, we need to take a test-first approach and see if the spec actually defines behavior.
<AmeliaBR> Dirk: But do we have agreement on what should happen?
<AmeliaBR> Amelia: Maybe come back with tests for all the combinations, but no references & then we can go through and discuss what should happen.

[svgeesus]

Conclusion from WG discussion was that we need tests to be able to discuss the issue and see what existing implementations do.

So we need tests. Then discussion, and a resolution of #629