Rotating text

[r12a]

11.2.2. Notes on 'x', 'y', 'dx', 'dy' and 'rotate'
https://svgwg.org/svg2-draft/text.html#TSpanNotes

Rotation of red text inside the ‘text’ element:

What happens for indic scripts, where the typographic unit or more needs to be rotated as a unit? Should the spec rotate CSS's typographic units rather than characters?

[AmeliaBR]

Would this be covered by the bullet point for "When there is a many-to-many mapping of characters to glyphs" ?

Or would it be better to replace all references to "glyph" in that list with "typographic unit" ?

[r12a]

Would this be covered by the bullet point for "When there is a many-to-many mapping of characters to glyphs" ?

If i correctly understand, i don't think it would. I imagine that it depends on the font as to what the mapping is between glyphs and characters in an indic syllable, but i suspect that there are plenty of cases of one-to-one mappings, albeit with GSUB or GPOS rules involved. I have to admit, though, that i'm not sure of the answer here.

[nikosandronikos]

I'm not an expert on this. Though the guy that sits next to me is, so I've been picking his brains.

At first I thought that using the term glyph was wrong and we shouldn't be using it here, because depending on the font, the number of glyphs used to represent the same unit* can change. But I've changed my mind - see below.

*unit is my term because I'm not sure what the correct term is here

For example:
Á is U+0041 combined with U+0301 and is treated as a single unit (can't be broken).
It could be represented as a single glyph, or as two glyphs (with the diacritic being moved into position using the gpos table).

In either case, it should consume one of 'x','y','dx','dy', or 'rotate'.

Here's why I've changed my mind - I think the phrase that @AmeliaBR referenced does handle this correctly in both cases. Depending on the font, it will be either a many to one mapping, or a many to many mapping. It looks like both should provide the correct result.

Testing implementations, Firefox is mostly right, Chrome/WebKit is wrong. Chrome/WebKit breaks up the 'units', while FireFox doesn't, but may be consuming the elements of the 'x','y','dx','dy', or 'rotate' arrays incorrectly.
Test: https://jsfiddle.net/dodgeyhack/trmxc73n/

[nikosandronikos]

*unit above should be replaced with 'user perceived character' or grapheme cluster.

[Tavmjong]

Rotation should be done by CSS typographic units. This is the definition of a typographic unit.

[nikosandronikos]

Think we're all in agreement with what should be done - we just need to check that the spec is describing that - then we can close the issue.

[fantasai]

Rotation should be done by CSS typographic units, yes. However, the counting should be in something more deterministic--Unicode codepoints, addressable characters, or Unicode grapheme clusters.

[r12a]

Also note that Unicode's grapheme clusters don't actually cut the mustard when it comes to consonant clusters in scripts like Devanagari (used for Hindi/Marathi/Nepali), Bengali, etc. In these cases the 'conjunct' or 'grapheme' formed by a cluster of consonants, plus possible vowel or other attachments, may need to be treated as a unit, but is composed of more than one 'grapheme cluster'. There is some discussion going on at the Unicode Consortium at the moment about how this could be improved, but no clear idea yet about what the solution should be. It's also complicated by the fact that typographic units for a specific script can vary, depending on what typographic operation you're trying to perform.

There's a picture and simple description of this problem at http://r12a.github.io/scripts/tutorial/part3#graphemes

In the meantime, some text is probably needed in specs that says "Watch out though, as sometimes you'll need to use typographic units that are bigger than grapheme clusters!"

[Tavmjong]

I find the current text (from SVG 1.1) to be overly complicated. I propose the following replacement text which should also address the issues here:

The attribute 'x', 'y', 'dx', 'dy', and 'rotate' are applied as follows:

• The n-th value maps to the n-th input character (i.e. Unicode code point) in the text (after white-space collapse). Bidirectional text re-ordering does not change this mapping (values are attached to input characters and move with them as they are reordered).
• All glyphs that belong to a typographic character are transformed as a group using the values from the first input character in the typographic character.
• For input characters in a typographic character other than the first: 'x' and 'y' values are ignored; 'dx' and 'dy' values are summed and applied to following typographic characters; the last 'rotate' value is applied to following typographic characters (if not over-ridden by a child element).

[AmeliaBR]

The n-th value maps to the n-th input character (i.e. Unicode code point) in the text

That part is, sadly, not web compatibility. The mapping is based on UTF-16 byte-pairs, aka JS string numbering.

For input characters in a typographic character other than the first: 'x' and 'y' values are ignored;

Should be x, y, and rotate are ignored, since they are all non-cumulative.

the last 'rotate' value is...

This is a separate bullet point. I'd clarify as "the last 'rotate' value in the list is applied to all following typographic characters in the element".

I'll still need to review the old text to make sure there are no other details dropped.

[css-meeting-bot]

The Working Group just discussed Rotating text, and agreed to the following:

• RESOLUTION: Text layout attributes should apply to typographic units as a whole

The full IRC log of that discussion

<krit> topic: Rotating text
<krit> GitHub: https://github.com//issues/260
<krit> Tav: this requires WG resolution though it is not a big chnage
<krit> Tav: in SVG 1 everything was about rotating characters
<krit> AmeliaBR: I'd separate last bullet point into 2
<krit> Tav: SVG 1.1 talks about chars or glyphs. We actually want graphical units called typographical characters
<krit> Tav: the glyph changes depending on the font and shaping engine.
<krit> Tav: so you really want to use the smallest peace of text that has to stay a unit
<krit> Tav: for western languages there really is no differences but for east/mid/south asian languages it gets very complicated.
<krit> Tav: since we change talking from glyph to typorgrahic characters we need to agree on a glyph.
<krit> krit: So minor change with bigger influence on certain languages
<krit> AmeliaBR: pretty much
<krit> krit: I am fine with the change.
<krit> suggested resolution: Text layout attributes should apply to typographic units as a whole
<krit> RESOLUTION: Text layout attributes should apply to typographic units as a whole

[Tavmjong]

Tests show that all but Firefox use Unicode code points in mapping to 'x', 'y', 'dx', 'dy', and 'rotate' attributes. See #537

[dirkschulze]

Closing in favour of
#537