The Unicode Consortium Discussion Forum

Proposal to Revise UTR #50 describes a character property, Orientation_Class, which provides a classification of characters that can be used to determine the orientation of glyphs of arbitrary text content in a vertical layout.

The proposed Orientation_Class differs from the DVO and EAVO properties in the third Proposed Draft UTR #50 in that it supports two vertical layout modes in a single property: a default vertical layout mode and a vertically stacked layout mode.

Details are provided in the proposal document. Comments are welcome.

I think the reviewers would benefit greatly if you provided the data part in a machine readable form.

I really like Laurenţiu's model here. This seems like more of a Bidi_class, where some characters need to know the surrounding context in order to be displayed properly, and therefore heritability is necessary. There are two distinct areas that neither the EAVO/DVO nor the Orientation_Class seem to fully support/distinguish, but OC seems to be zoning in on, namely:

1) Scripts like Mongolian and 'Phags Pa that are inherently vertical, but would (possibly) be rendered "stacked" horizontally with an upright instead of rotated orientation in the absence of cursive rendering. Maybe OC=VRS (Vertical script rotated or stacked horizontally)?

2) Scripts like Tibetan that are cursively joined and layed-out horizontally, but are rendered in vertical context upright, with the cursive breaks indicating a vertical line break. http://www.tibetan-calligraphy.com/tattoos/components/com_virtuemart/shop_image/product/Simple_vertical__4b64625d55d2a.gif Would OC=SR cover this?

Let's refer to this proposal as L2/02-012, since that's the L2 doc number for it.

I found a minor error in the Notes fields in Table 3:

FF00 Cn S U S Wide ‘!’
FF01 Po TS U U Wide ‘"’
FF02..FF03 Po S U U

The "Wide ‘!’" should be FF01 and "Wide ‘"’" should be FF02.


Shinyu Murakami
Antenna House

I generated a machine and human readable file from [L2/12-102] Table 3 (Orientation_Class property values) and put it in my site temporarily until better one is published:

http://nadita.com/murakami/utr50-ms-table.txt

Shinyu Murakami
Antenna House

Some question:

Why ‘°’ (U+00B0 DEGREE SIGN) is S (Stackable only)?
I think RS (Both rotatable and stackable) will be better. For example, when ‘12°34′56″’ is written in default vertical layout, it will be odd if '°' is not rotated while digits and primes (oc=RS) are rotated.

Why ‘±’ (U+00B1 PLUS-MINUS SIGN) is S (Stackable only)?
It seems exceptional while most math symbols including ‘+’ (U+002B PLUS SIGN), ‘−’ (U+2212 MINUS SIGN), and ‘∓’ (U+2213 MINUS-OR-PLUS SIGN) are RS.

Why Box Drawings (U+2500..259F) are S (Stackable only)?
I think they should be R (Rotatable only), same as dashes.

Why Roman Numerals are RS (Both rotatable and stackable)?
We expect the pre-combined Roman Numerals [ⅠⅡⅢⅣⅤⅥⅦⅧⅨⅩⅪⅫⅰⅱⅲⅳⅴⅵⅶⅷⅸⅹⅺⅻ] are upright in default vertical layout. See the Wikipedia's description:
http://en.wikipedia.org/wiki/Unicode_numerals#Roman_numerals



Regards,

Shinyu Murakami
Antenna House

Why Fractions [¼½¾⅐⅑⅒⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞⅟] and ‘/’ (U+2044 FRACTION SLASH) are S (Stackable only)?

I understand we will often expect the pre-combined Fractions [¼½¾⅐⅑⅒⅓⅔⅕⅖⅗⅘⅙⅚⅛⅜⅝⅞] are upright in vertical layout, but ‘/’ (U+2044 FRACTION SLASH) and ‘⅟’ (U+215F FRACTION NUMERATOR ONE) are used together with superscript and subscript numbers (oc=RS) and cannot be upright in default vertical layout.


Shinyu Murakami
Antenna House

Why ‘〓’ (U+3013 GETA MARK) is TR (Transform Rotatable)
and ‘゠’ (U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN) is TS (Transform Stackable)?

As far as I know, the Geta mark ‘〓’ (used as replacement character) is always upright, and the double hyphen ‘゠’ must be rotated in Japanese vertical text layout.


Shinyu Murakami
Antenna House

I agree. Is it possible to post a data file? That helps the review at CSS WG a lot.

Thank you so much to all reviewers for the comments.


The question is valid and the model extensible, but the proposal aims to provide a default classification for vertical text layout. Nonetheless, it would be interesting to see if evidence of upright, disconnected Mongolian or 'Phags-pa in horizontal layout exists.


A specialized vertical text layout that stacks morphemes instead of glyph clusters is conceivable. The proposed property provides a classification which any generic vertical layout can use. With the proposed RS classification, a specialized layout could conceivably accomplish a more complex stacking either via a shaping system that produces larger glyph clusters or by another layout process. The inclusion of the tsheg is worth researching further for the more general case of punctuation marks such as the apostrophe (or even modifier letters) that can appear together with a preceding character as one cell in a vertically stacked layout. Thank you for providing the Tibetan sample.


The L2 document number is L2/12-102.


Those two comments are indeed off by one table row. Thank you for pointing that out.


Thank you so much for the excellent feedback. Some property values were assigned based on evidence of attested usage, others were derived algorithmically from other UCD properties, such as General_Category or East_Asian_Width. As a result, some assignments need finer adjustment, and expert feedback such as this is most valuable. We will apply all of the suggested changes, except for the following, where further comments are sought:

• The box drawing pieces are a rather special category of symbols, in a way similar to arrows, which have their own class A. Rather than introducing a distinct class, the box drawing characters were assigned the value S because they are intended for compatibility with older mechanisms of character cell graphics, which can imply a specialized layout where the characters are individually picked for their 2D connectivity.
• Regarding the fractions, could you please provide samples where U+2044 and U+215F are used with superscripts and subscripts, if available?

The data, although not in a machine readable format, is included in the proposal annex.

Indeed. Sorry about that.

The Wikipedia's article about the fraction slash says: “The fraction slash is used in the display of ratios and fractions, as in constructing a fraction using superscript and subscript” (http://en.wikipedia.org/wiki/Slash_(punctuation)#Arithmetic).

Thank you for the resource.