Version reviewed: http://www.w3.org/TR/2008/WD-SVGMobile12-20080915/
Lead reviewer and date of initial review: Richard Ishida, Oct 2008
Subject lead in: [1.2T-LC]
These comments have not yet been endorsed by the I18N Core WG. The "Owner" column indicates who has been assigned the responsibility of tracking discussions on a given comment. This review covers the chapters on Text and Fonts.
We recommend that responses to the comments in this table use a separate email for each point. This makes it far easier to track threads. Click on the icons in the right-most column to see email discussions.
|1||10.2||Explanation of ligatures||
"(Note that for proper rendering of some languages, ligatures are required for certain character combinations.)"
"Composite characters - In various situations"
"Some typography systems examine "
"In some languages, particular sequences of characters "
I would change 'some' and 'various' to 'many'. Ligatures are required in scripts all across Asia, and composite messages are even more common. Especially since this is SVG Tiny, and will therefore play a role in the mobile Web, I think it's important to make implementers consider support for complex script features. I did some testing of the font features and noted that OpenType features required for the Indic scripts I tested were not supported. This is a common scenario, and has been for a long time. I don't think implementers are actually aware of the fact that ligatures and such are not just frilly features for most languages throughout Asia. I'd generally like to see a little more emphasis on this in the document. (I'd have actually liked to see a graphical example of rendering in a complex script here - i may be able to provide one if you like.)
"given a geometric coordinates"
-> given geometric coordinates
|3||10.3||Inline -progression typo||
"particular text layout and bidirectionality"
|5||10.4||Characters and glyphs||
"The 'text' element renders its first glyph (after bidirectionality reordering) at the initial current text position, which is established by the 'x' and 'y' attributes on the 'text' element (with possible adjustments due to the value of the 'text-anchor' property). After the glyph(s) corresponding to the given character is (are) rendered, the current text position is updated for the next character. In the simplest case, the new current text position is the previous current text position plus the glyphs' advance value."
I think this should say "the current text position is updated for the next glyph" not "character", since there are numerous scripts where a combining character combines to the left of the glyph for the base character or characters in left-to-right text (for a simple example, see the second para at http://rishida.net/scripts/myanmar/#vsplacement, where the second glyph from the left is displayed before the two characters that follow it). The current text makes it sound like most scripts are like English.
|6||10.4||Direction and bidi-override attributes||
The direction and bidi-override attributes are needed to establish a context so that the bidi algorithm can work. My understanding is that this was omitted unintentionally and will be put back in. This comment is based on the latest editor's copy of the document (ie. more recent than the version most of these comments apply to.)
"In most cases, the bidirectional algorithm from [UNICODE] produces the desired result automatically, and overriding this algorithm properly is usually quite complex. Therefore, in most cases, authors are discouraged from assigning values to these properties."
Actually, it's only in simple cases that you get the desired result automatically. For example, just put a period or other punctuation at the end of any Arabic or Hebrew text, and it will appear in the wrong place (at the right side) unless you have set the directional context, since the default is LTR. You could say that in *many* cases the bidi algorithm produces the result automatically, in which case it is not necessary to use the markup, but you can't say that in most cases authors are discouraged from using the attributes. Usually, however, it is not complex to use these properties, either. If you're working in Arabic, you'll most likely need to set the direction to RTL most of the time.
Perhaps it would be helpful to provide an example of the most straightforward case, ie. unicode-bidi="embed" direction="rtl", that people can cut&paste.
What *would really* be helpful, would be the possibility of declaring the direction at the top of the document, ie. in the svg element, and allowing it to cascade from there to all text elements. In *that* case, you are much less likely to need to set the properties on each text element, when working in a right-to-left script. (And it will save a lot of typing for the poor Middle Eastern authors.)
"For top-to-bottom text, the block-progression-direction always points 90 degrees counter-clockwise from the reference orientation vector because the only available top-to-bottom writing mode is tb-rl."
|8||10.7||Text rendering order||
"The glyphs associated with the characters within text content block elements are rendered in the logical order of the characters in the original document, independent of any re-ordering necessary to implement bidirectionality. Thus, for text that goes right-to-left visually, the glyphs associated with the rightmost character are rendered before the glyphs associated with the other characters"
Does this allow for reordering of glyphs in Indic and South East Asian languages, where the glyphs are not in the same order as the characters in the text stream?
|9||10.8.1||Geometric middle of the text string||
"middle The rendered characters are aligned such that the geometric middle of the text string is at the current text position."
It could be made clearer that this refers to the geometric middle of the resulting rendered text, rather than the text string, since 'text string' commonly refers to the characters in memory. This behaviour has to take into account combining characters, conjunct forms, and character widths in the rendered text.
|10||10.11.5||Up down top bottom||
"For top to bottom vertical (vertical Chinese, etc): start=up and end=down"
I suggest "start=top and end=bottom".
|11||10.11.7||Last in text area||
"The last in text area extent includes the advance of a trailing soft hyphens but does not include the advance of trailing white space or combining marks."
soft hyphens -> soft hyphen
I think 'combining marks' should become 'non-spacing combining marks'.