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

And yes in my logic case the uax#50 logic is not followed so it is simpler. If we were to use uax50 we would need more steps to handle the sometimes R cases for example.

-Nat
________________________________
From: 木田泰夫 <kida@mac.com>
Sent: Friday, July 16, 2021 5:50:07 PM
To: Nat McCully <nmccully@adobe.com>
Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
Subject: Re: AJ1 (vert) と UAX#50 の食い違いの分析

Actually, if you follow UAX#50 shouldn’t it be like this?

[cid:9CD679F4-BC02-4801-89E6-E69E8FCCD547]

2021/07/17 9:40、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:

Correction: Please ignore the “No” after the “Apply vert” box.

2021/07/17 9:38、木田泰夫 <kida@mac.com<mailto:kida@mac.com>>のメール:

Thank you. Just to be clear, applications in general as the first step determine if the character should be rotated, and if so “vert" is ignored if it exists.

<PastedGraphic-1.png>

木田

2021/07/17 9:15、Nat McCully <nmccully@adobe.com<mailto:nmccully@adobe.com>>のメール:

The logic is:


  1.  Use application logic or UTR#50 to determine if “R”
     *   If “R”, rotate.
     *   If not “R”, add vert and set upright.


--Nat


From: 木田泰夫 <kida@mac.com<mailto:kida@mac.com>>
Date: Friday, July 16, 2021 at 5:10 PM
To: JLReq TF 日本語 <public-i18n-japanese@w3.org<mailto:public-i18n-japanese@w3.org>>
Subject: Re: AJ1 (vert) と UAX#50 の食い違いの分析

質問：「vert なし」の場合に縦になるか横になるかは、純粋にアプリケーションの動作に依存するという理解で正しいですか？


2021/07/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
//