Accumulated Feedback on PRI #253

This page is a compilation of formal public feedback received so far. See Feedback for further information on this issue, how to discuss it, and how to provide feedback.

Date/Time: Mon May 27 22:51:10 CDT 2013
Contact: cewcathar@hotmail.com
Name: C. E. Whitehead
Report Type: Public Review Issue
Opt Subject: Draft UTR #50 Vertical Text Layout


Hi, I've looked somewhat carefully at the summary and first four sections of
this draft, and just have a few proofreading nits:

http://www.unicode.org/reports/tr50/tr50-9.html

Summary, 2nd par, 3rd sentence

"For example, in East Asia, Han ideographs, Kana syllables, Hangul syllables, 
and Latin letters of acronyms are upright, while words and sentences in the 
Latin script are typically sideways."

==>

"For example, in East Asia, Han ideographs, Kana syllables, Hangul syllables, 
and Latin letters in acronyms are upright, while words and sentences in the 
Latin script are typically sideways."

{ COMMENT: I changed "of" to "in" -- I found "letters of acronyms" 
understandable but odd-sounding. }

* * *

Section 1, 2nd par

"In many parts of the world, most characters are upright, as can be seen 
in figure 2. "

==>

"In many parts of the world, characters may be displayed as upright, as 
can be seen in figure 2. "

{COMMENT: Latin characters which are not part of texts with non-Latin
characters are only displayed upright in certain situations, for example,
because of space layout, as was the case in the picture, figure 2; that's what
you say right below and what you say below is fine; but the 2nd paragraph, as
is, seems to contradict what you say below}

 * * *

Section 1, 7th par

"The intent is that document formats should offer to the author the
possibility of specifying the desired orientation of a given character (or
even better, of a given character occurrence)

{COMMENT: can you define in this draft how "a given character occurrence" is
different than "a given character" [Maybe it's me but I'm completely baffled.
If it's just me, forget this] }

* * *

Section 1, 10th par (not counting crossed out par -- thus this is the
penultimate par in section 1), 2nd sentence

"For characters that are not generally used in such environments, similarity
"to existing characters has been taken into consideration.

{ Just a request for clarification, if you have time: Will characters that are
 similar to existing characters generally follow same pattern in terms of
 their display in vertical texts?}

* * *

Section 3.1, First item

"Characters which are displayed upright, with the same orientation as they
"appear in the code charts

==>

"Characters which are displayed upright, with the same orientation as they
"appear with in the code charts

{COMMENT:  "they appear" sounds strange in your sentence: yes characters can
appear but  the focus is not on the characters' appearing but on their
orientation -- thus it's better to say instead, "with the same orientation
that they appear with in the code charts"; alternately you might say "with
the same orientation that appears in the code charts" but "same orientation
as they appear in the code charts" makes no sense, because syntactically the
orientation of the characters displayed upright has to be explicitly
connected to their orientation in the code charts; that is you've got to
refer to the orientation of the characters in the code charts and not just to
the characters in the code charts. Hope this makes sense.}



Section 3.3, First par, first sentence

"The Unicode code charts generally show characters in the orientation when
used in horizontal lines. However, there are a few exceptions, mostly for
characters or scripts which are normally written in vertical lines; in those
cases, the code charts show the characters in the same orientation as in
vertical lines.

==>

"The Unicode code charts generally show characters in the orientation they
take when used in horizontal lines. However, there are a few exceptions,
mostly for characters or scripts which are normally written in vertical
lines; in those cases, the code charts show the characters in the same
orientation as in vertical lines.

{COMMENT: o.k but it might be better to explicitly specify that the characters
TAKE THE ORIENTATION when THE CHARACTERS ARE USED IN horizontal LINES. Your
subsequent sentence is o.k. I think because you used "as in" before  "vertical
lines" and it's clear that it's the orientation you are referring to.}


Best,

--C. E. Whitehead
cewcathar@hotmail.com




Date/Time: Fri May 31 00:55:49 CDT 2013
Contact: cewcathar@hotmail.com
Name: C. E. Whitehead
Report Type: Public Review Issue
Opt Subject: Unicode Technical Report 50


Again I've only got proofreading comments -- I can see this is an unfinished
draft awaiting comments (a couple of typos, a long sentence, and I'm confused
about your use of the words "code points" -- I think you mean that you want
feedback on certain "points," not "code points"; sorry I can't offer more than
proofreading: http://www.unicode.org/reports/tr50/tr50-10.html

Section 5, last par: "HALFWIDTH characters have value Tr since when there was
a discussion whether it should be upright or rotated, and it was not revisited
since then. UTC will discuss whether it is better to keep them as Tr, or
should be changed to R and therefore removed from this table."

=> "since a discussion on whether half-width characters should be upright or
rotated, HALFWIDTH characters have had the value Tr.  This issue has not been
revisited since then. UTC will discuss whether it is better to keep these
characters [really characters' value] as Tr, or whether they should be changed
to R, and therefore removed from this table."

{ COMMENT: (1), verb tense: the present tense is not the best for beginning
this sentence; rather a perfect tense verb, which indicates that the action
has been true since a date in the past, is better; the present is used for
either things that happen repeatedly, or for facts that are true -- always
true; next, the past tense is used for actions completed at some time in the
past; use instead the perfect when the action occurs up to the present -- for
example the issue has not been revisited up to the present -- so use a present
perfect to signal this; 
(2), articles: it's better to use an article before
the noun "value" since "value" is a "countable" noun, that is an item can have
one or more values; thus I inserted the article "the" before the word "value;"
(3), subject of verb -- always needs to be clear: what is it that should be
upright or rotated? the half-width katanka? Also, the subject of "should" is
not made clear in "should be changed to R."  Finally I took the liberty to
break the first sentence here into two sentences. Hope that's o.k. }

* * * 

Section 6, par 2

"Reviews and feedback are apprecaited in general, but even more appreciated 
to the following code points. "

=>
"Reviews and feedback are appreciated in general, but even more appreciated 
on the following {?} points. "

{ COMMENT: "appreciated" is the correct spelling -- probably a typo;
in my English dialect, we say "comments on" not "comments to;"
do you want "comments on the following points" (issues) or "comments on 
the following code points"?  -- I am confused by the words "code points" 
here; sorry. }


* * *

Section 6, bulleted list, first item

{ COMMENT:"typographers" is the correct spelling -- probably a typo here again.}


Best,
--C. E. Whitehead
cewcathar@hotmail.com

Date/Time: Wed Jun 5 16:47:41 CDT 2013
Contact: lunde@adobe.com
Name: Ken Lunde
Report Type: Public Review Issue
Opt Subject: PRI #253 (Draft UTR #50) comments


1) In Section 5, Table 4, there are some issues:

The vertical glyphs for U+337B through U+337F are unchanged from their
horizontal versions. The first four should be stacked, and the fifth should be
reordered, like the katakana ligatures that immediately precede these five
characters. I can provide the glyphs.

The vertical glyph for U+FF01 should be adjusted to the upper-right corner,
and should remain upright.

There should be a second vertical glyph for U+FF1A, which is adjusted to the
upper-right corner. In other words, there are two conventions for the vertical
version of this character. Japanese rotates it, but Chinese and Korean shift
it to the upper-right corner.

The vertical glyph for U+FF1B should be unrotated and adjusted to the upper-
right corner. Japanese uses it as-is, but Chinese and Korean shift it to the
upper-right corner.

U+FF61 through U+FF70 should be removed from the table, because their property
value is simply R.

2) Remove the Tx property value on the grounds that no character uses it. Given 
that the two fallback choices, Tr and Tu, represent a binary condition, the Tx 
property value seems to not serve any real-world purpose.

3) Datafile suggestions:

Change U+00B0, U+2032, and U+2033 from R to Tr. A large number of Japanese
fonts map these characters to full-width glyphs, and provide vertical
variants.

Change U+FF1D from R to Tr.

Change U+FF1F from U to Tu. This is for parity with U+FF01. (This also means
adding U+FF1F to Table 4 in Section 5.)

Change U+309D and U+309E from Tu to U. (This also means removing them from
Table 4 in Section 5.) Typical Japanese fonts use the same glyphs for both
horizontal and vertical writing. Note that whatever is done with these two
characters, there should be parity with their katakana counterparts, U+30FD
and U+30FE. In other words, assign the same property value to all four
characters.

Remove U+D800 through U+DFFF. This range doesn't seem to belong.

About arrows and line-drawing characters, these are all currently set to R,
which is reasonable, but I am wondering whether Tr might be a better default,
which allows for deferring to the font. This is especially useful when the
selected font's em-box is non-square, and mechanical rotation would provide
undesirable results.

In general, the presence of the Tr and Tu property values is quite nice,
because it indicates both a reasonable default behavior, but still allows the
font to control the behavior. For this reason, when in doubt, I would favor Tr
and Tu over R and U. This seems to apply mainly to arrows and line-drawing
characters.

Date/Time: Fri Jun 14 03:11:24 CDT 2013
Contact: siqinbilige@gmail.com
Name: SiqinBilige
Report Type: Public Review Issue
Opt Subject: There is a big problem with Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) in UTR#50 Revision 10.


There is a big problem with Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) in UTR#50 Revision 10.
http://www.unicode.org/Public/vertical/revision-10/VerticalOrientation-10.html

Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) marked as U(Characters
which are displayed upright, with the same orientation as they appear in the
code charts. ) in  in UTR#50 Revision 10.

Mongolian-based systems are typically written using a top-to-bottom inline
direction with a rightward (left-to-right) block flow direction.
http://dev.w3.org/csswg/css-writing-modes/#text-flow

For the readability reason Mongolian and Phags-pa characters listed upright in unicode chart.
Mongolian(U+1800-U+18AF) : http://www.unicode.org/charts/PDF/U1800.pdf
Phags-pa(U+A840-U+A87F)  : http://www.unicode.org/charts/PDF/UA840.pdf
And some system unicode font included it exactly as it was.

But, there is a fact about Mongolian(U+1800-U+18AF) and Phags-
pa(U+A840-U+A87F). Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) is
complex script like arabic. The code and glyph in Mongolian(U+1800-U+18AF) and
Phags-pa(U+A840-U+A87F) not one to one relation, but one to many relations.
So, the glyphs in this unicode font has no usefull for
Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F).

There is no OS with vertical layout. The height of glyphs in
Mongolian(U+1800-U+18AF) font is all diffrent and the glyphs must connected
each other(no space) in one word. It is difficult to create a font with
upright glyphs for Mongolian(U+1800-U+18AF).

For the readability of Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) in
horizontal layout (Figure 3. Mongolian text on horizontal lines) and the
difficulty of create font with upright glyphs for Mongolian(U+1800-U+18AF) and
Phags-pa(U+A840-U+A87F), all existing Traditional Mongolian (0x01800 -
0x018AF) and Phags-Pa ( 0x0A840 - 0x0A87F ) OpenType/TrueType/AAT fonts have
counter-clockwise rotated glyphs.

For, example.
  1. TrueType fonts of Menksoft(蒙科立) which using unicode private area.
  2. TuteType fonts of  Founder Group (方正集团)  which using unicode private area
  3. Opentype font, Mongolian Baiti, Microsoft PhagsPa font of Microsoft windows 7,8.
  4. OpenType/AAT font, Mongolian White of Almas.
       The fonts of Almas can download from www.mongolfont.com.
        For Windows 7,8 (OpenType) : http://www.mongolfont.com/jAlmas/cms/documents/mongolfont/font/mnglwhiteotf.ttf
        For Mac OS X (AAT) : http://www.mongolfont.com/jAlmas/cms/documents/mongolfont/font/mnglwhiteaat.ttf

According to the above reason The glyphs in Traditional Mongolian and Phags-Pa
font should be rotated in vertical layout.  Property value of
Mongolian(U+1800-U+18AF) and Phags-pa(U+A840-U+A87F) should be R, not U.

Recently a patch of webkit which about UTR#50 was landed.
Titled as "Character orientation should follow UTR50 specs for vertical layout".
https://bugs.webkit.org/show_bug.cgi?id=112213

For this reason, all Traditional Mongolian(U+1800-U+18AF) home page is currently 
broken on some latest verstion of browser which using webkit.

For example, http://www.mongolfont.com/. it is currently broken on
  Latest version of Google chrome, Google Chromium and Opera Next on Mac OS X and Android.
  Safari on iOS7.

SiqinBilige


From: Laurentiu Iancu
Subject: RE: UTR #50 Mongolian feedback
Date: Fri, 14 Jun 2013 22:20:44 +0000

The Vertical_Orientation property values are assigned to denote whether
rotation (or typographic transformation) does or does not occur w.r.t. to the
orientation given in the character code charts.  For Mongolian and 'Phags-pa
characters, the Vertical_Orientation property value U denotes that no rotation
occurs compared to the respective code charts.  How a given rendering system
accomplishes that orientation is implementation specific and takes into
account the orientation of glyphs in the fonts it works with.

Please refer to Section 3.3 of UTR #50
(http://www.unicode.org/reports/tr50/tr50-10.html#vertglyphs):

«
Some rendering systems include glyphs that are rotated counterclockwise with
respect to the characters as shown in the code charts, and expect applications
to rotate them clockwise in vertical lines. For example, OpenType fonts that
support Mongolian and Phags-pa typically follow this convention.

While this property defines only default orientations compared to the code
charts, high-level protocols or applications that make use of such rendering
systems could combine information provided in a font's tables with the
property values to more reliably calculate in which orientation they should
render such glyphs, in order to achieve the desired visual result.
»
- - - - - - - -