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

山本さん、村田さん、ありがとうございます。


> U+2702 ✂


ハサミは気がついてはいたのですが、調査対象とした JLReq / JIS X 0213 に含まれないんですよね。WAVY DASH は村田さんのプレゼンにあったから例外的に入れたのですが。U+2702 も結構使われているんですかね？

UAX#50 では矢印のように方向性を持ったものはほぼ R なのですが、これは絵文字カテゴリなのか U ですね。


山本さんのコメント：
> そのため、韓国語や中国語簡体字で用いられるコロン、セミコロン、感嘆符、疑問符に対応しているとはいえません。
> 

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


確かに。とはいえ JIS X 0213 に含まれていて、日本語入力ソフトで簡単に入力できてしまいますから（少なくとも mac では。Windows はどうですか？）デジタルテキストの中ではある程度使われていそうです。

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


全角中心で回転、EPUB リーダーや web での実際はどうなんでしょう？　これらによる回転がちゃんとしていたら、グリフを実装する必要が低いことになりますね。一度調査すべき？　また、全角中心で回転が重要なら、それをどこかに記述（JLReq）すべきでしょうね。（todo二つ）

機構的には、これらは石井さんが言われた ‘vrtr’ に移行すべきなのかな？

回転といえば、一般的にプロポーショナルグリフ、例えば英字や記号、を正立で使うと必ずしも重心が真ん中に来るとは限らないように思えます。UAX#50 には EAW=N を正立させる例が多数ありますが、これはどうなんでしょうね？（調査？）


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

そうなんですよね。中途半端ですよね。そういう意味では、和文フォントなら記号的に使われていると推測して U 扱い、それ以外なら R 扱い、という InDesign の動作は合理的かもしれませんね。


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


最後の section 3、ちゃんと読んでいなかったのですが、結構重要なところですね。この表を見ると、UAX#50 はクォーテーションマーク類が簡体繁体中国語で回転しない（’vrtr’ 必要）という問題がありますね。

コロンセミコロンで若干の齟齬がありますが、UAX#50 が Tu / Tr の場合、どちらにせよ vert を呼ぶので、事実上は問題がない、との解釈で正しいでしょうかね。例えば全角コロン U+FF1A の場合、UAX#50の期待は Tr ですが、別に vert によって本当に回転したかチェックするわけではないので、Tu 動作の簡体中国語と韓国語も OK、U 動作の繁体中国語は vert がないのでこれも OK、Tr 動作の日本語は期待通り。もちろん実装が異なると問題が出る可能性がありますが、この辺り、石井さんコメントありますか？

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

これは確かに問題だと思います。U なら必ず vert を通してくれるとの保証があれば良いのですが。


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


これは縦横動作関係なく重要な問題ですよね。ダッシュ類、リーダ類、クォーテーション類が該当しますが、どうするのが良いでしょうね。

木田

> 2021/07/19 20:08、MURATA Makoto <eb2m-mrt@asahi-net.or.jp>のメール:
> 
> 皆さん、
> 
> 私が以前に求めた結果は、Excelの表にまとめてあります。これを
> 提供すべきでした。木田さん、すみません。
> 
> https://onedrive.live.com/edit.aspx?resid=4106E423DCEF597E!40113&authkey=!ANKIRw9Mw4agscU <https://onedrive.live.com/edit.aspx?resid=4106E423DCEF597E!40113&authkey=!ANKIRw9Mw4agscU>
> 
> ×#1: AJ1x のフォントでは横倒し、UAX#50 では正立にになるケース
> 
> これには、
> U+2702	✂
> もあります。
> 
> 村田
> 
> 2021年7月16日(金) 20:30 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>:
> JLReq TF の皆さま、
> 
> 縦書き字形の AJ1x (vert) と UAX#50 の食い違いを分析しました。前回山本さんに InDesign を通した分析を説明していただきました。かなり複雑で私の頭がパンク。しかし、アプリケーションの動作を抜いて、純粋に AJ1x フォントの挙動と、UAX#50 の比較をしたところ、かなり単純化できました。
> 
> （Natさん、山本さん、石井さん、私の報告の解釈が合っているか、チェックしていただけますか？）
> 
> vert と UAX#50 の値の組み合わせは下のように8通りあります。それぞれの組み合わせに番号が振ってあります。
> 　○ は両者が一致している場合
> 　△ は縦横は一致しているが字形に食い違いのある可能性がある場合
> 　× 縦横が食い違う場合
> 
> 調査対象の文字はJIS X 0213 / JLReq、およびJIS外だが以前村田さんのレポートにあったWAVY DASH U+3030です。
> 
> 
> vert あり
> vert なし
> UAX#50 = U
> 1
> × 双柱
> 5
> ○
> UAX#50 = R
> 2
> △ ハイフン、リーダ、矢印、度分秒
> 6
> ○
> UAX#50 = Tu
> 3
> ○
> 7
> ○ 全角感嘆符疑問符
> UAX#50 = Tr
> 4
> ○
> 8
> × 全角セミコロン、WAVY DASH
> 
> 
> ×のケース、△のケース、および○の#7 について説明します。
> 
> × 両者で回転が異なるケース - 3文字
> 
> ×#1: AJ1x のフォントでは横倒し、UAX#50 では正立にになるケース
> 
> これは一つだけです
> U+2016	双柱, DOUBLE VERTICAL LINE
> 
> 双柱は「句読点、記号・符号活用辞典（小学館）」p. 44 によると、区切りの線として使うとあります。その場合、縦横で方向が変わる必要がありますので、こちらは AJ1x の挙動が期待に合っていることになります。
> 
> ×#8: AJ1x のフォントでは正立、UAX#50 では横倒しになるケース
> 
> 二つあります。
> U+FF1B	全角セミコロン, FULLWIDTH SEMICOLON
> U+3030	WAVY DASH
> 
> このうち、全角セミコロンは、全角コロンに vert が存在することから、vert のバグかと思われます。U+3030 WAVY DASH は DASH ですので、UAX#50 の言うように、行の方向に従って回転するのが自然な気がします。つまりこれも UAX#50 で良いかと。つまり両方のケースで AJ1x から挙動を変えた方が本来は良さそうに見えます。ただし互換性の問題があるので、では変えましょうとは言えるのかどうか。
> 
> 結局、決定的な食い違いがあるのは村田さんのレポートにあった二文字 ＋ 全角セミコロンだけ、という結果になりました。
> 
> 
> △ 縦横は一致しているが字形に食い違いのある可能性のある場合
> 
> △#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
> 
> 問題はフォントが位置や形を調整したグリフを持っているのか、縦書きの時に真ん中に来るのか、でしょうか。この点どうでしょう？ > 山本さんかな？
> 
> 面白いことに、四分のハイフンは vert があるのに、二分ダーシには vert がありません。
> 
> 
> ○ 問題ないケースのうち、#7 にコメント
> 
> ○#7: 両方とも正立：UAX#50 はもしかしたら特別製の正立グリフがあるかも、と vert をかけてみるのですが、AJ1x フォントには vert のないケース
> 
> 全角の感嘆符と疑問符です。このケースはアプリケーションが UAX#50 に対応しても現れるグリフに変更はなく、懸念はないかと思います。UAX#50 はどのような理由でこれらを Tu にしているのか興味があります。
> U+FF01	全角感嘆符, FULLWIDTH EXCLAMATION MARK
> U+FF1F 全角疑問符, FULLWIDTH QUESTION MARK
> //
> 
> 
> 
> -- 
> Regards,
> Makoto