[css-writing-modes] Clarify the baseline value during the top-to-bottom writing mode for Latin text

[RazrFalcon]

Moved from w3c/svgwg#619

https://www.w3.org/TR/SVG/text.html#WritingModeProperty
https://www.w3.org/TR/css-writing-modes-3/#vertical-modes

It's probably CSS Writing Modes Level 3 related. I'm not sure. For now, I'm experiencing the problem during the SVG 1.1 rendering, but I'm sure that this can be reproduced in HTML too (I'm not familiar with it).

<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="120" y="30" writing-mode="tb">Text</text>
    <rect id="frame" x="1" y="1" width="198" height="198" fill="none" stroke="black"/>
</svg>

As you can see, the text has a different baseline(?). Which one is the correct one? Is this explained somewhere?

[fantasai]

Those should not be differing by implementation...
Is there a difference between implementations if you don't have writing-mode specified?

[fantasai]

The SVG specs are very vague as to what should be happening here, but I think what they're supposed to say is that the alphabetic baseline (a metric defined in the font file itself) is aligned to the alignment point you're specifying in the x and y attributes. In a correctly-developed font, that point will coincide exactly with the bottom of the capital T and lowercase x, and be slightly above the bottom of the lowercase e (due to optical alignment effects). Afaict, all those renderings are a bit off: that point should coincide exactly with the middle of the gray stroke.

Variant of this testcase using Ahem

I think what needs to happen here is importing the testcase into WPT and filing bugs against all browsers. :( But thanks for the example and testcase!

[fantasai]

Filed w3c/svgwg#629 against the SVG spec. I think for Writing Modes there is nothing to be done here.