RE: AJ1 (vert) と UAX#50 の食い違いの分析

木田さん、

こんにちは。返信が遅れ申し訳ありません。いくつか以下にコメントいたします。

×#1: AJ1x のフォントでは横倒し、UAX#50 では正立にになるケース

これは一つだけです
U+2016                 双柱, DOUBLE VERTICAL LINE

双柱は「句読点、記号・符号活用辞典（小学館）」p. 44 によると、区切りの線として使うとあります。その場合、縦横で方向が変わる必要がありますので、こちらは AJ1x の挙動が期待に合っていることになります。

U+2702 BLACK SCISSORS

もこれに該当すると思われます。

×#8: AJ1x のフォントでは正立、UAX#50 では横倒しになるケース

二つあります。
U+FF1B                 全角セミコロン, FULLWIDTH SEMICOLON
U+3030                 WAVY DASH

○ 問題ないケースのうち、#7 にコメント

○#7: 両方とも正立：UAX#50 はもしかしたら特別製の正立グリフがあるかも、と vert をかけてみるのですが、AJ1x フォントには vert のないケース

全角の感嘆符と疑問符です。このケースはアプリケーションが UAX#50 に対応しても現れるグリフに変更はなく、懸念はないかと思います。UAX#50 はどのような理由でこれらを Tu にしているのか興味があります。
U+FF01                 全角感嘆符, FULLWIDTH EXCLAMATION MARK
U+FF1F                 全角疑問符, FULLWIDTH QUESTION MARK

Adobe-Japan1グリフ集合は、日本語フォントのためのグリフ集合です。そのため、日本語で最低限必要になるか、日本語関連の標準的な文字・グリフ集合、外字フォントなどで広く含まれているグリフを含んでいますが、日本語以外の言語で用いるグリフについては、対応していません。そのため、韓国語や中国語簡体字で用いられるコロン、セミコロン、感嘆符、疑問符に対応しているとはいえません。

また、コロン及びセミコロンは日本語の縦組みにおける用法が確立していないように思います。コロンを欧文と同様の目的で使う用法も、やはりまだ便宜的と考えられます。

#2: 両方とも横倒し：AJ1x のフォントでは縦書き用グリフが個別にあるが、UAX#50 は、それを無視してアプリケーションが機械的に横倒しにすることを指定しているケース

おそらくほぼ似た結果になるのですが、フォントが位置や形を調整したグリフを持っていても無視されることになります。該当文字は：
U+2010                 ハイフン（四分）/ハイフン  HYPHEN
U+2025                 二点リーダ                TWO DOT LEADER
U+2026                 三点リーダ                HORIZONTAL ELLIPSIS

U+00B0                 度              DEGREE SIGN
U+2032                 分              PRIME
U+2033                 秒              DOUBLE PRIME

U+FF1D                 全角等号 FULLWIDTH EQUALS SIGN

U+2190                 左向矢印 LEFTWARDS ARROW
U+2191                 上向矢印 UPWARDS ARROW
U+2192                 右向矢印 RIGHTWARDS ARROW
U+2193                 下向矢印 DOWNWARDS ARROW
U+21C4                 右矢印左矢印           RIGHTWARDS ARROW OVER LEFTWARDS ARROW
U+21E6                 左向白矢印                LEFTWARDS WHITE ARROW
U+21E7                 上向白矢印                UPWARDS WHITE ARROW
U+21E8                 右向白矢印                RIGHTWARDS WHITE ARROW
U+21E9                 下向白矢印                DOWNWARDS WHITE ARROW
U+261E                 指示マーク                WHITE RIGHT POINTING INDEX

U+2500-2542                         BOX DRAWINGS なんちゃら

U+2015                 HORIZONTAL BAR HORIZONTAL BAR

UAX #50がRとしている文字にvertのグリフで対応している文字は以下です。

U+00B0    °
U+2010    ‐
U+2015    ―
U+2025    ‥
U+2026    …
U+2032    ′
U+2033    ″
U+2190    ←
U+2191    ↑
U+2192    →
U+2193    ↓
U+21C4    ⇄
U+21C5    ⇅
U+21C6    ⇆
U+21E6    ⇦
U+21E7    ⇧
U+21E8    ⇨
U+21E9    ⇩
U+239B    ⎛
U+239C    ⎜
U+239D   ⎝
U+239E    ⎞
U+239F    ⎟
U+23A0    ⎠
U+23A1    ⎡
U+23A2    ⎢
U+23A3    ⎣
U+23A4    ⎤
U+23A5    ⎥
U+23A6    ⎦
U+23A7    ⎧
U+23A8    ⎨
U+23A9    ⎩
U+23AA   ⎪
U+23AB   ⎫
U+23AC   ⎬
U+23AD   ⎭
U+23B0    ⎰
U+23B1    ⎱
U+2500    ─
U+2501    ━
U+2502    │
U+2503    ┃
U+2504    ┄
U+2505    ┅
U+2506    ┆
U+2507    ┇
U+2508    ┈
U+2509    ┉
U+250A    ┊
U+250B    ┋
U+250C    ┌
U+250D   ┍
U+250E    ┎
U+250F    ┏
U+2510    ┐
U+2511    ┑
U+2512    ┒
U+2513    ┓
U+2514    └
U+2515    ┕
U+2516    ┖
U+2517    ┗
U+2518    ┘
U+2519    ┙
U+251A    ┚
U+251B    ┛
U+251C    ├
U+251D   ┝
U+251E    ┞
U+251F    ┟
U+2520    ┠
U+2521    ┡
U+2522    ┢
U+2523    ┣
U+2524    ┤
U+2525    ┥
U+2526    ┦
U+2527    ┧
U+2528    ┨
U+2529    ┩
U+252A    ┪
U+252B    ┫
U+252C    ┬
U+252D   ┭
U+252E    ┮
U+252F    ┯
U+2530    ┰
U+2531    ┱
U+2532    ┲
U+2533    ┳
U+2534    ┴
U+2535    ┵
U+2536    ┶
U+2537    ┷
U+2538    ┸
U+2539    ┹
U+253A    ┺
U+253B    ┻
U+253D   ┽
U+253E    ┾
U+253F    ┿
U+2540    ╀
U+2541    ╁
U+2542    ╂
U+2543    ╃
U+2544    ╄
U+2545    ╅
U+2546    ╆
U+2547    ╇
U+2548    ╈
U+2549    ╉
U+254A    ╊
U+261C    ☜
U+261D   ☝
U+261E    ☞
U+261F    ☟
U+27A1    ➡
U+2B05    ⬅
U+2B06    ⬆
U+2B07    ⬇
U+FF1D   ＝

問題はフォントが位置や形を調整したグリフを持っているのか、縦書きの時に真ん中に来るのか、でしょうか。この点どうでしょう？ > 山本さんかな？

フォント側では、アプリケーションが、日本語のために、全角中心で回転してくれるかどうか予知不能であるため、日本語組版の縦組みにおいて全角中心で回転した形状が必要と考えられる最低限のグリフをvertが対応している、と考えられます。

以前から述べていることですが、全角の中心で回転すべき日本語のグリフを正確に回転してくれることが保証されないと、このvertの内容を無視することはできないように思います。（このことは、歴史的に、いかに多くのPCアプリケーションが日本語組版における全角ボディの重要性について無知であったかを示唆していると、いえるのかもしれません）

面白いことに、四分のハイフンは vert があるのに、二分ダーシには vert がありません。

Adobe-Japan1ではShift-JIS由来の日本語の文字では、ハイフンとダッシュなどの記号類も全角ボディ付になっています。日本語用の半角、三分、四分グリフはGSUBで対応していますが、縦組みでそれらがRとして自動的に回転されるかどうかは、該当する文字コードが欧文領域にあるかどうかに依存すると思います。Nat, please confirm this point. I am not perfectly sure about it.

ギリシア文字は UAX#50 では外国語と見て横倒し、InDesign でも欧文書体だと横倒しですが、和文書体だと「α線」のように全角文字が記号的に使われているという前提で正立させます。フォントを UAX#50 に沿わせる場合は和文書体でも（UAX#50はテキストや書体の言語を区別しません）ギリシア文字は横倒しとなり、よってプロポーショナルなグリフの出てくることが期待されるでしょう。もちろん全角のままでも良いのですがプロフェッショナルな結果とはみなされないでしょう。つまり UAX#50 の指定するアプリケーションの動作は間接的にですがフォントにも影響があることになります。

先のダッシュ類にも関係しますが、Adobe-Japan1のグリフは日本語の慣習に合わせたものです。また、Shift-JISからの慣習を引きずっているだけではなく、日本語で使われる以外の文字体系に本格的に対応する必要がある場合には、専用の欧文フォントを用いる必要があり、逆にその必要が無い場合には、ビュレットの代わりなどの用途で、記号的に全角の欧文その他の文字体系の文字が使われるという、日本における慣習に対応したものとなっています。

そのため、例えば、Adobe-Japan1だけに対応した日本語フォントで、ギリシア語の文章を組むことは不可能です。ギリシア語で必要となる句読符号、アクセント、その他特殊なグリフを欠いているからです。

ギリシア文字やロシア文字のグリフをプロポーショナルに切り替えるべきだ、という考えは何年も前からあるのですが、これまでそうしなかった主な理由は、非互換性が発生するためですが、それ以外にも、たとえそうしたとしても、それだけでは欧文やギリシア／ロシア語をまともに組めるようにはならないことも要因として考えられます。「プロフェッショナル」なギリシア／ロシア語組版の要求に応えるには、専用のギリシア文字フォントが必要と考えます。なお、このことは、ラテン文字についてもある程度はいえることで、本格的な欧文組版に必要とされるグリフにすべて対応しているわけではありません。

先にお送りしたvertの資料がこのメールで触れた内容に相応したものとなっていますが、先にお送りした、SummaryUTR50issue1.3というPDFファイルも同様にvertとUAX #50との関係を調べたものです。

Adobe-Japan1はあくまで日本語を目的としたグリフ集合ですが、他方で、例えば日本、中国語簡体字、中国語繁体字、日本語用の漢字、韓国語用の漢字、香港用の漢字に対応するPan-CJKフォントの「源ノ角ゴシック」や「源ノ明朝」では、先に述べた、中国・日本・韓国での句読符号の位置関係の違いについても対応する必要がありました。この点については、上に述べたSummaryUTR50issue1.3の末尾に、「源ノ角ゴシック」のREADMEファイルから引用した表があります。ただ、それらへの対応は、現時点では一般の日本語用のフォントが対応する範囲を超えたものとなっています。

また、これは繰り返しになりますが、デザイン上の要求から、Uの文字例えば平仮名やカタカナのグリフをvertに含めることで、縦組み用に最適化されたグリフのデザインを提供している場合があります。そのため、そのような場合にアプリケーションがvertを無視すると、期待通りの組版結果が得られなくなります。

また、U+2014とU+2015の例のように、組版上は必要となる欧文と和文とのグリフの区別が文字コード上は包摂されてしまっている場合についても、対応が必要と考えます。

以上、あくまで私の考えです。間違っている点等あるかもしれません。ご指摘ください。

山本太郎
アドビ