The Unicode Consortium Discussion Forum

The Unicode Consortium Discussion Forum

 Forum Home  Unicode Home Page Code Charts Technical Reports FAQ Pages 
 
It is currently Fri Oct 31, 2014 4:10 am

All times are UTC - 6 hours [ DST ]





Post new topic Reply to topic  [ 14 posts ] 
Author Message
 Post subject: A proposed Orientation_Class property
PostPosted: Wed Mar 07, 2012 9:31 pm 
Offline

Joined: Thu Feb 11, 2010 12:47 pm
Posts: 11
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.


Last edited by iancu on Thu Aug 09, 2012 7:03 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Thu Mar 08, 2012 11:17 am 
Offline
Unicode Guru

Joined: Fri Dec 04, 2009 9:25 pm
Posts: 76
I think the reviewers would benefit greatly if you provided the data part in a machine readable form.


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Thu Mar 08, 2012 6:27 pm 
Offline

Joined: Mon Feb 01, 2010 6:18 pm
Posts: 79
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?


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Fri Mar 09, 2012 2:24 am 
Offline
Unicode Guru

Joined: Fri Dec 04, 2009 9:25 pm
Posts: 76
Let's refer to this proposal as L2/02-012, since that's the L2 doc number for it.


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Fri Mar 09, 2012 10:14 am 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Fri Mar 09, 2012 10:37 am 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Fri Mar 09, 2012 1:41 pm 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
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
Quote:
... One reason for the existence of pre-combined numbers is to facilitate the setting of multiple-letter numbers (such as VIII) in a single "square" in Asian vertical text....



Regards,

Shinyu Murakami
Antenna House


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Fri Mar 09, 2012 8:38 pm 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Sat Mar 10, 2012 1:21 am 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Sat Mar 10, 2012 12:34 pm 
Offline

Joined: Wed Dec 07, 2011 3:01 am
Posts: 71
emuller wrote:
I think the reviewers would benefit greatly if you provided the data part in a machine readable form.

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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Mon Mar 12, 2012 4:54 pm 
Offline

Joined: Thu Feb 11, 2010 12:47 pm
Posts: 11
Thank you so much to all reviewers for the comments.

vanisaac wrote:
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)?

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.

vanisaac wrote:
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?

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.

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

The L2 document number is L2/12-102.

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

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

MurakamiShinyu wrote:
Why ‘°’ (U+00B0 DEGREE SIGN) is S (Stackable only)?
[...]
Why ‘±’ (U+00B1 PLUS-MINUS SIGN) is S (Stackable only)?
[...]
Why ‘〓’ (U+3013 GETA MARK) is TR (Transform Rotatable)
and ‘゠’ (U+30A0 KATAKANA-HIRAGANA DOUBLE HYPHEN) is TS (Transform Stackable)?

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?

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

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

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


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Mon Mar 12, 2012 7:42 pm 
Offline
Unicode Guru

Joined: Fri Dec 04, 2009 9:25 pm
Posts: 76
Quote:
The L2 document number is L2/12-102.


Indeed. Sorry about that.


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Tue Mar 13, 2012 12:35 pm 
Offline

Joined: Sat Jan 14, 2012 4:10 am
Posts: 29
iancu wrote:
  • Regarding the fractions, could you please provide samples where U+2044 and U+215F are used with superscripts and subscripts, if available?

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).


Top
 Profile  
 
 Post subject: Re: A proposed Orientation_Class property
PostPosted: Wed Mar 14, 2012 3:19 am 
Offline

Joined: Thu Feb 11, 2010 12:47 pm
Posts: 11
MurakamiShinyu wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


Quick-mod tools:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Template made by DEVPPL.com