UTR#50 MS提案について
MURAKAMI Shinyu
http://unicode.org/forum/viewtopic.php?f=35&t=277
[L2/12-102] Updated Proposal to Revise UTR #50 Unicode Properties for Vertical Text Layout
http://www.unicode.org/~iancu/12102-update-utr50.pdf
このPDFのTable 3: Orientation_Class property values を扱いやすいようテキストにしてみました：
http://nadita.com/murakami/utr50-ms-table.txt
oc欄の見方：S=常に正立、RS=回転と正立、R=回転、TS=変形正立、TR=変形回転、A=矢印（高位プロトコルで決める）、詳しくはPDFを参照。
このMS案のデータで気になった点をいくつか：
■‘°’ DEGREE SIGN が常に正立(oc=S)
00B0 So S U U ‘°’
※360°の360が回転して°が正立というのは変なのでoc=RS（回転と正立）のほうが適切ではないか。'°' とともに使われるPrime記号（2032..2037）はoc=RSである。
■‘±’ PLUS-MINUS SIGN が常に正立(oc=S)
00B1 Sm S U U ‘±’
oc=S(常に正立)。ほとんどの数学記号がoc=RSであり、'+' PLUS SIGN (002B)、'−' MINUS SIGN (2212)、'∓' MINUS-OR-PLUS SIGN (2213)がoc=RSであるのに '±' ばかりがoc=Sというのはなぜだろう。
■Box Drawingが常に正立(oc=S)
2500..257F So S S U/S Box Dra
2580..259F So S S U/S Blocks
■分数が常に正立(oc=S)
2044 Sm S S U/S Fract. ‘/’
2150..215F No S U U Fractions
■ローマ数字は回転と正立(oc=RS)
2160..2182 Nl RS U U № Form
英数字を回転するときはローマ数字も回転。
--
村上 真雄 (MURAKAMI Shinyu)
Twitter: http://twitter.com/MurakamiShinyu
Blog: http://blog.antenna.co.jp/CSSPage/
Antenna House Formatter:
http://www.antenna.co.jp/AHF/
MURAKAMI Shinyu
http://blog.cas-ub.com/?p=1272
に、この提案の概要が紹介されてます。
方向属性と方向クラス(Orientation_Class)の説明があります。
> このPDFのTable 3: Orientation_Class property values を扱いやすいようテキストにしてみました：
> http://nadita.com/murakami/utr50-ms-table.txt
各方向クラスにどの文字が含まれるかが分かりやすいように、方向クラス別に分けたファイルも次のところに置きました：
http://nadita.com/murakami/utr50/
このMS提案の方向クラスで、いちばん議論になりそうなのは、方向クラスR（回転のみ）に含まれる文字についてです。これらの文字は、正立モード（text-orientation:upright）であっても回転することになります。
括弧類やダッシュ類がこれに含まれるのは自然だと思います。
アラビア文字など続けて書く文字もこれに含まれています（独立字形を1文字ずつ正立させるべきという意見と対立しているし、BIDIの扱いも問題）。
私がとくに興味深いと思うのは、数学記号のうち、等号・不等号など（<=>≒≦≧など）がこのR（回転のみ）に含まれることです。詳しくはそのデータ
http://nadita.com/murakami/utr50/utr50-ms-table-R.txt
全角文字の＜＝＞は、方向クラスTR（縦書き字形があればそれを使って回転）ということで、やはり正立モードでも回転するということになります。
http://nadita.com/murakami/utr50/utr50-ms-table-TR.txt
等号・不等号などは両側の関係を表すので a≦b が縦書きでaとbが正立でも≦は回転というのは論理的です。また、＜＞は括弧のように使われることがあるし、＝はダッシュのように使われることがあるので、括弧やダッシュ類と同じく常に回転というのは便利であるようにも思います。
しかし、正立モード（text-orientation:upright）を指定しても正立にならないのはおかしいと、反対がありそうです。正立にならない文字を正立にするには縦中横（text-combine-horizontal）を使うしかないということになります。
私は、正立モードを定義するのに、今のCSS3 Writing ModesのEditor's DraftのAppendix C
http://dev.w3.org/csswg/css3-writing-modes/#vertical-typesetting-details
にあるsideways(Sv)カテゴリ（常に回転、MS提案の方向クラスR相当）の定義（含まれる文字はモンゴル文字、スペース類、接続記号類、ダッシュ類（ハイフンも含む）、罫線素片など）が妥当なところでないかと思ってたのですが、まだまだ議論が必要なようです。
--
村上 真雄 (MURAKAMI Shinyu)
Twitter: http://twitter.com/MurakamiShinyu
Blog: http://blog.antenna.co.jp/CSSPage/
Antenna House Formatter:
http://www.antenna.co.jp/AHF/
MURAKAMI Shinyu <mura...@antenna.co.jp> wrote on 2012/03/10 1:59:19
Koyama Tadayoshi
このMS提案の方向クラスで、いちばん議論になりそうなのは、方向クラスR（回転のみ）に含まれる文字についてです。これらの文字は、正立モード（text-orientation:upright）であっても回転することになります。
括弧類やダッシュ類がこれに含まれるのは自然だと思います。
Koji Ishii
> 日本語では普通の平仮名やカタカナも縦書き横書きで字形が異なることはよくありますので、
> 通常の平仮名、カタカナを MS 提案でいう S から TS に変更すべきと思いますが、いかがでしょうか。
>
>（仕様に入らない場合、恐らくリーディングシステム実装者は平仮名カタカナについては方向クラスを
> 無視して勝手にGSUBを牽くことになり、せっかくの規格が不備なものとなってしまいます）
このご質問は、CSS3 Writing Modes/EPUB3の上でのご質問と理解してよろしいでしょうか？ UTR#50がまだ未完なこともあり、ご質問の背景によって適切なお答えが変わってくるかと思っております。とりあえずその前提で私の理解する現状をお話します。
UTR#50はUnicodeレベルの定義のため、アプリケーションがどのようにこの仕様を解釈するかはアプリケーションに任されています。たとえばT, Tu, Trの「fallback」をどのように定義するか、という部分に関しては、現在もこの先も定義する予定はありません。CSSをお使いであれば、この部分はCSSが定義することになります。
CSS WG内の議論では、フォントによって向きが変わるのは避けてほしい、という要望が出されています。CSSにはフォントフォールバックの機構があるので、フォールバックによって向きが変わるのは避けたい、あるいはフォントを決定する前にrunを切ってしまうブラウザーがあり、フォントが決まった後に向きが変わる＝runの切り直しになり、コードの複雑さやパフォーマンスに影響が出る、などの意見が出されています。
このため、現在のCSS WGの方針としては、U/T/Tu/Trはすべてvertをオンにして正立描画、Rのみ回転描画、vrt2は使わない、と定める予定になっています。詳細省いていますが、一部例外がありまして、間違った実装を防ぐため、CSS WGでこの計算をしたテーブルを提供する方向で検討中で、その最新版は現在こちらにあります。
https://bitbucket.org/kojiishi/ucd/raw/tip/vosimple.csv
今はまだMVOだけで、これにSVOも足して、CSVとUCDの両フォーマット対応などするつもりですが、見ていただければわかる通り、UとRしかありません。
ですので、CSS Writing Modes Level 3に準拠したアプリケーションをご検討する上では、U/T/Tu/Trに差は一切ない、と思って下さい。WGで過去の決議がひっくり返らない限り、Level 3ではこの方向です。
> 大方の議論がこのあたり、立てるか寝かせるかの話に集中しており、
> この点が見過ごされているようなのでちょっと古いものへの返信ですが書かせていただきました。
いえいえ、ありがとうございます。
私含むCSSエディター陣としては、長期視野でU/T/Tu/Trの差も含めて検討しています。が、少なくともCSSにとっては、この違いは将来のフォントベンダーがフォントを作る際に参考にする値としての位置づけであり、CSS UA/RSの実装に差がないことから、優先度を落として作業しています。
フォントを作っていらっしゃる、あるいはCSSではないUTR#50ベースのリーダーを作っていらっしゃるのであれば、回答が別になります。長くなりますのでとりあえず省きますが、その場合はご返信いただけますか？
よろしくお願いいたします。
Koyama Tadayoshi
このため、現在のCSS WGの方針としては、U/T/Tu/Trはすべてvertをオンにして正立描画、Rのみ回転描画、vrt2は使わない、と定める予定になっています。詳細省いていますが、一部例外がありまして、間違った実装を防ぐため、CSS WGでこの計算をしたテーブルを提供する方向で検討中で、その最新版は現在こちらにあります。
https://bitbucket.org/kojiishi/ucd/raw/tip/vosimple.csv
Koji Ishii
あ、そうでしたか、失礼しました。このレベルで議論をして下さる方はあまりいらっしゃらないので、自分の考えの見直しにもなりますし、大変助かります。ぜひお考え、いろいろお聞かせください。私はUTCのメンバーではありませんが、わかる範囲でお答えさせていただきます。
> 繰り返しになりますが、ユニコードの規格の解釈についてスクリプトエンジンが個々に行えば良い、
> というのはその通りなのですが、それはそれとして本来 Tu であるべき字が規格では U となってしまうと、
> その規格は規格として有用性が無くなるのではないか、ということです。
ご指摘の部分については、昨夏ごろに一度議論に上っています。あまりきれいにまとめたものや議事録がなくて恐縮なのですが、この辺
http://wiki.csswg.org/spec/utr50#the-east-asian-orientation-property
で起筆・終筆をどうするか、などの議論がありまして、現在の合意は、「スタイリッシュ用途の微細な違いはUTR#50では違いとして定義しない」という方向性が合意されています。それをどうするかは、フォントシステムとアプリケーションが別の仕様なり手法なりで行うもの、ということです。
縦横時のかな字形も議論の対象に一度上がりましたが、これは逆に日本側から「縦書きだったら自動的に縦字形とかにはしないでほしい」「するのはレベルが違う話なので間違いである」といった意見が出され、若干の混乱がありました。国内での話の次元として、UTR#50の想定するものと、印刷屋さんがDTPソフトに望むものなど、そもそものずれがあったとは思っていますが、起筆・終筆や「こどもの字」フォントに対して上記の結論が出たことから、かな字形も「スタイリッシュ用途」の問題と判断し、偶然ではありますが幸いにして国内意見を満たす結果となったので、そのまま終端させた経緯があります。
ですので、かなはUですが、UTR#50がどのように定義していても、フォント屋さんがvertにスタイリッシュな違いを入れることは可能であり、特に国内アプリにおいては、Uに対してもなるべくvertを尊重することが望まれます。ブラウザーも、当初一部反対はありましたが、今はvert適用で落ち着いています。ただ今までのアプリやvrt2での状況とは異なり、文字向きの責任がフォントからアプリに移ったことで、フォントの自由度が若干下がっています。具体的には、UTR#50でRと定められてしまったコードに関しては、フォント屋さんが例えばスタイリッシュな違いを入れたかったり、ベースライン位置の調整を縦書きでしたい、と思っても、少なくともCSSにおいてはvertを見なくなるため、反映する方法がなくなります。
フォント側からは「フォント設計の自由度をなるべく下げないでほしい」という要望をいただいていたので、R設定するコードポイントで日本で使われる可能性のあるものについては注意を払っているつもりではいますし、Adobeさん、自遊工房さんなどの方々にご協力いただいて、現在vertで回転しているものがアプリで回転するようになって問題ないかの簡単な確認などは行いました。一時期はその可能性のあるものを全部Trとし、それによってCSSでもvertの反映を可能にしようとしたのですが、それはそれでちょっと別の問題があり、一部は断念してRに戻したものもあります。また昨今は国内外二、三人から国内利用が多くないの文字をRに、という意見が上がっているので、もう少し増えるかもしれません。ここについては、私も気を付けてはいますが、「フォントの将来の可能性も含めた自由度」となると範囲が非常に難しい問題ですので、皆様にもぜひ随時レビューしていただいて、問題となる可能性が見つかったら教えていただけると大変助かります。
> 以下は１リーディングシステムの開発者としての観点からの、CSS 側の対応への疑問／感想です。
> もちろん無視していただいて構いません。万が一何かの参考になれば幸いです。
>> このため、現在のCSS WGの方針としては、U/T/Tu/Trはすべてvertをオンにして正立描画、
>> Rのみ回転描画、vrt2は使わない、と定める予定になっています。詳細省いていますが、一部
>> 例外がありまして、間違った実装を防ぐため、CSS WGでこの計算をしたテーブルを提供する
>> 方向で検討中で、その最新版は現在こちらにあります。
>> https://bitbucket.org/kojiishi/ucd/raw/tip/vosimple.csv
https://bitbucket.org/kojiishi/ucd/raw/201206/vosimple.csv
をご参照ください。現段階ではほとんど差はありませんが。
> これはつまり、R のみは回転する事が保証されているが、U/Tu/Tr についてはユニコードでこの3
> 種のどれと定義されていようと、使用するフォント ( 中のvert ) 次第で寝るものは勝手に寝る、
> 寝ないものは寝ない 、ということですよね。
そうなります。
> 「CSS WG内の議論では、フォントによって向きが変わるのは避けてほしい、という要望が出され
> ています」と考え合わせると、正立させたいが寝るかも知れない文字は U/Rなどの定義には頼らず
> CSS 的な解法ということになるのでしょうか。
http://wiki.csswg.org/spec/utr50/vert
これとUTRの値を突き合わせることで、あまりにひどい問題は出ない値を選ぶ、という前提です。ただ、vertテーブルは同じフォントでもバージョンで変わったりするし、世界中のフォントのテストを私一人ではできないので、全部カバーはできない、ということになります。お使いのフォントで問題のある値があれば、フィードバックしていただければ参考にさせていただきます、というレベルです。製品ではおそらく出荷前テストで300フォントくらいはテストしますが、CSSではそのレベルにはとても到達できません。この辺はボランティアなので、このレベルなんだ、というご理解をいただけると。
もう一点、UTR#50の背景として、CSSからの働き掛けもあったのですが、フォント側からも、vertを入れる基準がほしい、という話がありました。基準がないからそもそもバラバラになるのだ、ということで、UTR#50はこれも対象範囲としています。上記のようにスタイリッシュな変更はどこに入れてもよい（CSSではRは反映されませんが）が、Tu/Trについてはvertを入れることが推奨され、かつTu/Trに沿った向きに入れてほしいとUTR#50は考える、という意味を持ちます。
これにより、UTR#50が完成して5年、10年も経てば揃うだろう、というのが我々の意図です。製品作っていらっしゃる方にとっては、気の長い話で申し訳ないですが。
それが完成するまでの間のマイナーな問題に対しては、おっしゃるように個別に修正する以外道はありません。ただ個別に修正しても「正立＋vertなし」はCSSでは指定できませんので、それでも直しきれない問題がいくつかは出るだろうと思っています。そこはCSSでは完全に目を瞑る以外ありません。
> R 側以外の文字については現状と全く変わらず、文字クラスU、R を定める意味がないように思われます。
ただ、Trを入れれば、そこは今はばらばらでも将来的にすべてのフォントが回転字形をvertに入れてくる可能性が高くなりますし、Rを入れればフォントはブラウザーとの互換性を気にしてvertを入れない可能性が高くなります。CSSでは「正立＋vertなし」をやらないので、制作側が何をどうやっても正立にできない文字、という期待をUnicodeが世界中のアプリとフォントに対してしている、という意味になりますので、問題となる可能性を含むコードにR/Trが付いていないか、というのは、一人でも多くの方にレビューしていただければと思っています。私一人で全部に目が行き届いているか、というと、ちょっとそこまでは自信がありませんし、現在そういったレビューを手伝って下さる方はいらっしゃいませんので、これも個人のボランティアレベルのクオリティとお考えください。
> UTR#50はユニコードの規格であり、IDPF や W3C の立場とは離れて独自に修正、改版が行われるものと思われます。
> 電子書籍はファイルとして固定化されます。サーバに置かれたWEBページもかなりの程度はそうでしょう。
> 現行の CSS / EPUB 規格は、参照している規格の版をメタデータ内に記述しておりませんので、どの版の規格に準拠して
> テキストを解釈すれば良いのかが不明になってしまっております。今までこれが大きな問題になったことはないのですが、
> 記号の立つ寝るのように、テクストとしては同じなのだけれども視覚上大きな差異を生ずるような変更があり得るものに関しては、
> 参照する規格の版を決定できる仕組み（規格として refer している他の規格の版を固定する、プロパティで指定する、など）が
> あると良いなと強く思います。
そもそもUTR#50の最終版前に国内市場は離陸すると思っています。私個人の見解ですが、UTR#50は早くて半年、SVOがとても難しいので下手をするとあと数年かかると想定しています。ですので、UTR#50が最終版になる前に、この問題は出てくると想定しています。
Webについては、正直あまり妙案がないです。劇的に変わった場合にはCSSの別値を設けるなどの方法が考えられますが、それほど劇的に変わるとも思えません。いくつか策を練ってみたんですが、どれもあまりうまく行きませんでした。妙案がなく、Web縦書きがいつ離陸するかもグレーなので、私としては状況を見ている段階です。
EPUBについては、「参照先の仕様が変わった場合自動追随するが、その変更が後方互換性を壊す場合にはマイクロバージョンを上げる」という規定がありますので、これを利用することを考えています。とはいえ、各社さん、自社のリリース予定や、どのドラフトを採用するかなどについてはお話しいただけませんので、これも各社さんの動きを見ながら、後追い、ということになりそうです。
上記ファイルは私がトラックしていまして、これを一度WDとして出すことを今は最優先課題としています。WDが出れば、EPUBからは「自動追随」の対象になりますので、これを参照したUAが市場に出た後にUTR#50やCSSが変われば、EPUB WGに対してマイクロバージョンを上げるリクエストをすることができます。ほんとはもうWDが出ているくらいのタイミングを考えていたのに、ここのところちょっといろいろ気を取られることがあって進捗が芳しくないのが申し訳ないんですが、なんとか早めに進めようと思っています。いつ頃出そう、とかはなかなかお伝えしにくいんですが…特に公的なMLでは（笑 ご興味ありましたら、個人メールください。
文字向きの保全を気にされる場合には、まだバグだらけなのでいろいろとご不満はあるとは思いますが、上記ファイルか、UTRやCSSのどれかの公開された版を実装してくだされば、変わった場合にマイクロバージョンを上げられる可能性がありますので、より安全かと思います。
実装が終わり、マイクロバージョンを上げたい場合には、EPUB WGに入っていらっしゃるのであれば上記根拠より直接リクエストしていただいていいかと思いますし、私はメンバーではありませんがCSS WG/I18N WGからEPUB WGへのリエゾンをしているので、私にご相談いただいても構いません。ただ上記のように、なんらかの根拠のある実装をしていることが大事となりますので、そこだけご注意ください。
> 以上、乱文失礼いたしました。
とんでもございません、いろいろと私が考えていたことの中で、初めて議論ができたことがたくさんあり、私も自分の考えの整理になりました。整理していて思わず長文になってしまいましたが、ご容赦いただけますよう、よろしくお願いいたします。
MURAKAMI Shinyu
ツイッターでの議論（ハッシュタグ #UTR50）をまとめサイトに記録してます：
UTR#50（Unicodeの縦書きの文字の向き）の話題 #UTR50
http://togetter.com/li/251192
Unicodeのフォーラムでの議論も活発です：
http://unicode.org/forum/viewforum.php?f=35
だいたい3派に分かれているので、分かりやすく名前をつけてみました：
・英数字正立派
・正立優先派
・文字本来派
英数字正立派の主張は、日本語縦書きの実際の出版物で英数字は横倒しよりも正立で使われている頻度が高いのだから、正立を基本にすればマークアップが簡単になるはずというもの。詳しくは「縦組みにおける英数字正立論」（小林 徳滋）
http://www.cas-ub.com/project/sample/verticalwriting.pdf
http://www.cas-ub.com/project/sample/verticalwriting.epub
http://blog.cas-ub.com/
ちなみにUTR50では、縦書きの文字の向きとして、英数字を横倒しとする MVO (Mixed Vertical Orientation) のほか、ほとんど全ての文字が正立の SVO (Stacked Vertical Orientation) も定義されています。SVO を使うなら英数字正立派の要求を満足するように思えるのですが、UTR50ドラフト編者(Eric Muller)の意図では、日本語縦書き用は MVO だけということらしく、それでは SVO と MVO の役割はそれぞれ何だという議論があります：
http://unicode.org/forum/viewtopic.php?f=35&t=331
正立優先派の主張は、正立でも横倒しでも使われそうな約物や記号類は、できるだけ正立をデフォルトにしようというものです。横倒しをデフォルトにすると日本語の縦書きで使いにくくなるというのが主な理由とされます。英数字については全角文字を使うことで正立、通常文字を使うことで横倒しという従来の全角／半角の使い分けが想定されています。UTR50ドラフト編者(Eric Muller)がこの考えのようです。石井さんは、次のことも正立優先の理由としてます：
> UTR#50でRと定められてしまったコードに関しては、フォント屋さんが例えばスタイリッシュな違いを入れたかったり、ベースライン位置の調整を縦書きでしたい、と思っても、少なくともCSSにおいてはvertを見なくなるため、反映する方法がなくなります。
ダブルクオートのほか、欧文由来である記号類§©®™℀℅、数につく単位記号‰‱など、文字の本来の性質からは、横書き用と考えられる文字について、正立優先派と文字本来派とで意見が分かれています。
石井さんが触れている次のことがそれです：
> また昨今は国内外二、三人から国内利用が多くないの文字をRに、という意見が上がっているので、もう少し増えるかもしれません。ここについては、私も気を付けてはいますが、「フォントの将来の可能性も含めた自由度」となると範囲が非常に難しい問題ですので、皆様にもぜひ随時レビューしていただいて、問題となる可能性が見つかったら教えていただけると大変助かります。
違っていたら指摘ください。
私は文字本来派の方針が、仕様を分かりやすいものにするのによいと思っています。
Koyama Tadayoshi
switch (trcode) {
case tr50T: case tr50Tr: case tr50Tu:
{
BRFT_GlyphID vglyph = BRFT_GSUB_SubsisutateSingle(cjkFont->vert, glyph);
if ((trcode == tr50Tr) && (vglyph == glyph)) {
flags = gsRotate;
}
glyph = vglyph;
break;
}
EPUBについては、「参照先の仕様が変わった場合自動追随するが、その変更が後方互換性を壊す場合にはマイクロバージョンを上げる」という規定がありますので、これを利用することを考えています。とはいえ、各社さん、自社のリリース予定や、どのドラフトを採用するかなどについてはお話しいただけませんので、これも各社さんの動きを見ながら、後追い、ということになりそうです。
Koji Ishii
Writing-Modes Level 3のEDを先ほど更新しました。該当箇所はこちらです。
http://dev.w3.org/csswg/css3-writing-modes/#vertical-orientations
ちょっと他の部分との整合性等などはまだできていませんが、とりあえずこの節だけを見ていただければ、今までよりはわかりやすいかと思います。
ただここには書いておりませんが、個人的にはSVOの安定性は非常に悪いと思っていますので、あまり実装をお勧めできません。現段階では、upright時にはすべて（SVO=Rも含めて）正立、が、もっとも互換性の高い実装になると想定していますし、制作側の想定もそれに近いと理解しています。これは個人的な想定なので、何も保障にはなりませんが。
おっしゃられている問題はCSSでも何度か議論されていますが、よい解決策がありません。一時はCSSでもUにはvertを適用しない、という案もありましたが、それではやはり互換性の確保が難しいと思いますので、CSS同様にUにもvertを適用されたほうがよいかと思います。
ただ、じゃぁ、回転字形が入っているコードポイントはどうやっても正立にできなくなる、というのは避けようがなくなります。CSSは中長期で考えなければいけないので、この問題はそれほど起こらないという想定の元、時間が解決するのを待つことにしました。
もし私がCSSでない国内専用の実装を作るのでしたら、おそらくtext-orientationに独自の値を追加すると思います。デフォルトではvert適用、ただし（例えば）text-orientation:force-uprightの指定があればvert非適用、などです。判断しづらいところで個人的な直観になりますが、vertを適用するために起きる弊害は、適用しない弊害より低いと思われること、Wordなどの既存ソフトやCSSからの変換時の互換性はあった方がないよりは良いことなどから、製作者に万が一の場合の逃げ道として提供しておく、というオプションです。
長期的に見ても、例えばこれで一年経ってみて、作られたファイルを分析してみたら三万冊のうち1%の文書でこの指定がされていた、となれば、CSSに追加する提案も十分可能になりますので、互換性上も望ましいし、W3Cへのご貢献という意味でもぜひご検討お願いしたいと思います。