QSJN 4 UKR 於 2011年9月12日 下午9:06 寫道:

> I know it is sacred cow, but let me just ask, how do you people think.
> Is it good or bad that the codepoint means all about character: what,
> where, how... (see theme)? Maybe have we separate graph & control
> codes - wellnt have many problems, from banal ltr (( rtl instead ltr
> (rtl) to placing one tilde above 3, 4, anymore letters, or egyptian
> hierogliphs in rows'n'cols. Conceptually, I mean! Each letter in text
> is at least two codepoints ("what" and "where") in file. Is it stupid?
> Trying to render the text we anyway must generate this data.
> 


It's not really a sacred cow per se, but it is a fundamental architectural 
decision which would be pretty much impossible to revisit now.

Almost all writing is done using a small set of script-specific rules which are 
pretty straightforward.  English, for example, is laid out in horizontal lines 
running left-to-right and arranged top-to-bottom of the writing surface.  East 
Asian languages were traditionally laid out in vertical lines running from 
top-to-bottom and arranged right-to-left on the writing surface.  

Because some scripts are right-to-left and ltr and rtl text can be freely 
intermingled on a single line, Unicode provides plain-text directionality 
controls.  The preference, however, is to use higher-level protocols where 
possible.

As for the scripts which are inherently two-dimensional (using hieroglyphics, 
mathematics, and music), it's almost impossible to provide "plain text" support 
for them.  There is too much dependence on additional information such as the 
specifics of font and point size.  Because of this, the UTC decided long ago 
that layout for such scripts absolutely must be done using a higher-level 
protocol to handle all the details.

There are occasionally suggestions that positioning controls be added to plain 
text in Unicode, but so far the UTC has felt that the benefits are too marginal 
to overcome its reasons for having left them out in the first place.

=====
Hoani H. Tinikini
John H. Jenkins
jenk...@apple.com




Reply via email to