Notes on CSS Writing Modes Level 3

Last updated 5 October 2015

Introduction

Before CSS Writing Modes Level 3 can reenter CR there are two issues that remain pertaining to SVG. This page takes a closer look at those two issues.

Issue 47: Concerning 'writing-mode' and 'glyph-orientation'

Issue 47

This issue has to do with the properties 'writing-mode' and 'glyph-orientation'. The CSS WG want to know if the current draft:

Issue 53: Concerning 'writing-mode' computed values for 'rl' and 'lr'

Issue 53

This issue asks if both 'writing-mode' values 'rl' and 'lr' can be computed to 'horizontal-tb' or if the distinction between them must be preserved.

Detailed Discussion

Role of 'writing-mode' in SVG

In SVG 1.1, the purpose of 'writing-mode' is to set the inline-progression-direction. This is used along with other properties to determine the current text position. In other words, it helps to determine how glyphs are placed relative to each other. With a left-to-right value ('lr' or 'lr-tb') each subsequent glyph is place to the right of the previous. This gets complicated by the section Relationship with bidirectionality that dictates that the Unicode standard UAX9 should be applied to text layout. If Unicode information is available, this replaces the need for the inline-progresssion-direction. (An aside: the text reads almost as if Unicode was an afterthought.)

In SVG 1.1, the 'direction' property is used to set the base writing direction and the direction of embeddings and overrides. It also sets the reference point for determining the positioning of text using the 'text-anchor' property.

In SVG 1.0, things are a bit different. It appears that 'writing-mode' has the role in global layout that 'direction' takes on in SVG 1.1. In particular, SVG 1.0 states that 'direction' only has an effect if 'unicod-bidi' has a value of 'embed' or 'bidi-override' thus the value of 'direction' doesn't normally influence the positioning of Unicode directionally ambiguous characters (like some punctuation). This role seems to be left to 'writing-mode'. There is also no mention in the section for 'text-anchor' that it is the value of 'direction' that determines the alignment reference point. Again it appears to be 'writing-mode' that should be used and indeed in Batik, an early SVG renderer, this is the case. Opera (Presto) also appears to use 'writing-mode' rather than 'direction' (but the shift is incorrect).

In SVG 1.2 Tiny the text layout does not include the 'writing-mode' property and vertical text layout is not supported. The reference point for 'text-anchor' is explicitly linked to 'direction'. It appears that the authors, realizing that 'writing-mode' is missing, substituted 'direction' in its place for the purpose of 'text-anchor'. This then probably got carried over to SVG 1.1.

The SVG 1.1 test suite does not test 'text-anchor' on right-to-left text. 'writing-mode' is only tested in the context of vertical text. Tests for 'direction' explicitly include setting 'unicode-bidi' to 'bidi-override'.

Current use of 'writing-mode' in SVG

Adobe Illustrator, Adobe Photoshop, and Inkscape use the SVG 1.1 values for 'writing-mode' to distinguish between vertical vs. horizontal text. Illustrator and Photoshop always uses 'writing-mode: tb'. Inkscape uses 'tb', 'tb-lr', 'lr', 'lr-tb' written to a 'style' attribute.

Conclusions

Issue 47: Is the SVG WG happy with the current 'writing-mode' and 'glyph-orientation' text?

The 'note' in 3.1.1 I think should be removed. In SVG 1.1, the inline-progression-direction only seems to play a role in the absence of Unicode direction information so I don't think one needs to mention that here. The second paragraph is clearly wrong based on SVG 1.1. It is the 'direction' property that can cause text to shift (when coupled with the 'text-anchor' property) and reverse the order of glyphs (with 'unicode-bidi' value 'bidi-override').

In 3.1.1.2, there seems to be an error in the UA stylesheet: it should be 'horizontal-tb' not 'horizontal-tbl'.

The discussion of 'glyph-orientation' appears to match what we decided at the Paris 2015 FXTF meeting.

Issue 53: Can 'lr' and 'rl' both be aliased to 'horizontal-tb'?

I think the answer is yes. In SVG 1.0 there were two places where the values 'lr' and 'rl' could produce different results. The first is in the actual layout of text. This can only effect non-Unicode text. As Unicode is now ubiquitous, the need to specify an 'inline-progression-direction' in not needed. For the one place it could have an effect, determining the placement of Unicode ambiguous characters like '!', I see no evidence that any renderer changed behavior based on these values.

The second place in SVG 1.0 where the values could produce different results is when coupled with the 'text-anchor' property. Here, SVG 1.1 (and SVG 1.2 Tiny) are very explicit that alignment is to be done considering the 'direction' property. Whether or not this was a change from SVG 1.0 is moot.