As Andrew had already pointed out as general issue, the expected usecase of
the default value should be clarified. I'm afraid the preferences can be
varied in the cases like:
A) it is easy to rotate the material to harmonize the writing direction
and the eye-moving for natively laid-out texts, and the amount of the
strings to be red is small.
Like the maps, the engineering drawings, the circuit diagrams, etc.
B) it is difficult to rotate the material, but the amount of the strings
to be red is small.
B-1) The recognization is required to be quick.
Like roadway signs, etc.
B-2) The recognization is not required to be so quick.
Like spines of the books.
C) it is difficult to rotate the material, and the amount of the strings
to be red is large.
Like main text in the books.
Taking the current draft, the figure 1 and figure 2 may have different
background, the figure 1 is questionable if it is good example to show
the usage of default value. In fact, the vertical Latin like figure 1
is popular, but we should not expect as if it is common to find the
English books including whole texts are vertically typesetted as figure 1.
The situation where vertical texts like figure 1 is preferred would be
Stability of UTR#50.
The current draft of UTR#50 does not clarify the policies for the
stabilization. It should be clarified which values are stabilized,
which values are unstabilized, or just placeholders.
As Yi case (see my comments in below), the values in current UTR#50 have
different background. Some values are discussed with the experts who use
them, and other values are supposed without concrete evidences. Sometimes
the evidences were selectively sampled and some evidences are rejected.
In addition, the possibility should be considered that the preference of
the glyph rotation is not stabilized in the users community of some scripts.
Or, when the members of the user community is changed and the preference
The values determined by the discussions and the concrete evidences are
worthful to be kept compatible in future versions, but the guessed or
unstabilized values may be changed in future, so they should be excluded
from the stabilization.
Digraphs and Alphabetic ligatures
It seems that current draft (50-3) has no special rule for the digraphs and
alphabetic ligatures; U+01C4 - U+01CC, U+01F1 - U+01F3, U+FB00 - U+FB06.
I'm not sure if these characters are rendered with the values "U; S; S;".
Especially for the alphabetic ligatures, there is a possibility that these
characters are rendered by 2 alphabetic glyphs in vertical mode.
I'm suspicious about the hypothesis that the convention of the upright
Latin characters in vertical Japanese text was established with the
considerations of the digraphs, alphabetic ligatures, etc.
In fact, recently there was a discussion about the different requirement of
the alphabetical ligature in horizontal & vertical writing mode in OpenType
and ISO/IEC 14496-22 mailing list, raised by http://lists.w3.org/Archives/Public/www ... /0650.html
It was told that "fi" ligature should not appear in the vertical writing
mode for Japanese market.
Hiragana / Katakana voiced sound mark
The "uncombining" voiced sound mark U+309B, U+309C are rendered with the
values "U; U; U;". Modern orthography in Japan expects the voiced/semi-
voiced marks are put to the upper-light corner of the base characters.
In horizontal writing mode, the base character is rendered first, then,
the voiced/semi-voiced marks are rendered, so, usually the glyphs of
U+309B & U+309C designed for horizontal writing mode puts the marks on
the upper-left corners. If such (designed for horizontal writing mode)
glyphs are used in vertical writing mode, the result would be looking
like "a voiced/semi-voiced mark attached to the lower-left corner of
the previous character". I don't think it is expected result.
In fact, Adobe-Japan1 character collection has different glyphs for
U+309B & U+309C for vertical writing mode; CID+8171 & CID+8172. Thus,
the expected value would be "T; T; T;".
In addition, the glyph reordering or ligature formation is needed to render
with expected result in vertical writing mode. The voiced/semi-voiced marks
are expected to be put on the UPPER-right corner of the base character.
Thus, during top-to-bottom writing mode, the rendering of the voiced/semi-
voiced mark BEFORE the base character is expected.
However, the regular characters with voiced/semi-voiced characters are
already coded, so, I'm not sure what is the most popular usecase of the
uncombining voiced/semi-voiced marks. Some linguists may use them to
express the sound that cannot be expressed by standard kana, others may
use the irregular combinations just for joking.
According to the rotated N'Ko strings in maps: http://catalogingafricana.files.wordpre ... apada1.jpg http://catalogingafricana.files.wordpre ... cript1.pdf
it is questionable if the values for N'Ko "U; S; S;" are appropriate.
There is a possibility that "S; S; S;" might be preferred.
About UCS Yi, I support Andrew's comment. Some scanned images and photos
for Liangshan syllabicalized Yi in vertical writing mode without glyph
rotation are provided, but no strict evidences of the vertical text with
glyph rotation are given. If the samples by Andrew and me should be excluded,
the criteria for selective sampling should be clarified.
Hanunoo script is often mentioned with its special writing mode; from
bottom to top, but the glyph is always fitting to the writing direction http://scriptsource.org/cms/scripts/pag ... Hano&_sc=1 http://www.aa.tufs.ac.jp/i-moji/tenji/s ... mg/B03.jpg
If these description are true (and valid discussion for modern users),
the values for Hanunoo should be "S; S; S;" instead of "U; S; S;".
However I'm questionable if these scripts are used with same preferences
It is unclear if the glyph shaping of Arabic scripts is needed when
the rendering is done with default "upright" mode. If the glyphs are
disconnected from previous/next consonants, they should be rendered
with isolated form? If so, how the codepoints in Arabic presentation
form blocks should be dealt?
Also I note I could not find the book spines with the Arabic string
with upright mode.
Brahmic scripts (Indic, South-East Asian)
It is unclear if the clustering is needed when the rendering is done
with default "upright". If clustering is required, how the definition
of the grapheme is expected. The consonant and combining/enclosing
vowel signs should not be separated, but spacing signs & marks can
be separated? For example, tone marks of Tai Le are spacing characters.
They are expected to be put to the right neighborhood of previous
letters? Or, we can put them as different/isolated character?