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

木田さん、分析とまとめ、ありがとうございます。

ご質問の件：

全角セミコロンは、全角コロンに vert が存在することから、vert のバグかと思われます。


UAX#50では、コロン、セミコロンだけは例外扱いで、向きが不定になります。4 Glyphs Changes for Vertical
Orientation <http://unicode.org/reports/tr50/#vertical_alternates>
において唯一、両方の向きの事例が記載されています。これは慣習上、コロンを日本では横転するが、中国では正立（横書きと同じ）で、かつ右上や下に寄せて使う事例があるためです。
chwsのテストページ <http://kojiishi.github.io/chws/test.html>
で、Languageを変更していただくと確認できます。

セミコロンは、既存フォントにおいては、日本も含めてすべて正立（横書きと同じ）でした。このため、Ken
Lundeから横転字形を削除する提案が過去に上がっています。ただ木田さんもおっしゃるように、コロンを許容しつつ、セミコロンを許容しないのはロジカルでないと思われ、許容する分には問題が少ないであろうことから、同じグループに入れられています。

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

おそらくほぼ似た結果になるのですが、フォントが位置や形を調整したグリフを持っていても無視されることになります。


Rに対して別字形を設定する必要があるか、という議論がありました。「あるのではないか」という意見があったため、fantasaiが「vrtr」というfeatureを考えてCSSには記載しています
https://drafts.csswg.org/css-writing-modes-3/#typeset-sideways

が、実需用としてはまだ上がってきていないため、OpenTypeには入っていません。

次に、Tu/Tr ならフォントが適切なグリフを持っていることが期待されるのでそこには vert をかける。U
> ならどちらでも良いのですが、あまり細かくランを分けるのもパフォーマンスに影響するので、ここも vert をかける。結局 R 以外が連続した部分に
> vert をかけることになります。


> フォントに調節の自由度がないのは R である文字ということになります。また、Tr なのに vert が用意されていない場合は、UAX#50
> の期待と外れた方向になる。用意されていても、Tu/Tr/U の方向と違うグリフを持っていれば、UAX#50 の期待と外れた方向になります。


> これで正しいでしょうか？ > 石井さん


はい。5.1.2. Mixed Vertical Orientations
<https://drafts.csswg.org/css-writing-modes-3/#vertical-orientations>
が、木田さんのご説明に近いものになるかと思います。

Rの自由度については、上に書いた通りです。



On Sat, Jul 17, 2021 at 5:35 PM 木田泰夫 <kida@mac.com> wrote:

> 6/18 あたりの石井さんのメールを見ていると、典型的なアプリケーションの動作はどうもこうじゃないかなと思えてきました（下のフローチャート）。
>
> つまり、パフォーマンスもしくは他の理由で vert の有無を判断しないとしたら、UAX#50 が R
> の場合アプリケーションが自分で横転させるしかありません。さもないと、vert や横転グリフを持たないほとんどの欧文フォントで欧文が正立してしまいます。
>
> 次に、Tu/Tr ならフォントが適切なグリフを持っていることが期待されるのでそこには vert をかける。U
> ならどちらでも良いのですが、あまり細かくランを分けるのもパフォーマンスに影響するので、ここも vert をかける。結局 R 以外が連続した部分に
> vert をかけることになります。
>
> フォントに調節の自由度がないのは R である文字ということになります。また、Tr なのに vert が用意されていない場合は、UAX#50
> の期待と外れた方向になる。用意されていても、Tu/Tr/U の方向と違うグリフを持っていれば、UAX#50 の期待と外れた方向になります。
>
> これで正しいでしょうか？ > 石井さん
>
>
>
>
>
>
> 2021/07/17 16:52、Shinyu MURAKAMI <murakami@vivliostyle.org>のメール:
>
> > Checking if vert exists or not is too slow. We just set it on all
> upright characters.
>
> You mean "all U, Tu and Tr characters"? If so all Tr characters used in
> vertical text must have "vert" glyph.
> I think it was a mistake that U+3030 WAVY DASH (AJ1 has no "vert") is "Tr"
> in UAX#50.
>
> ---
> Shinyu Murakami
>
> On Jul 17, 2021, at 11:09, Nat McCully <nmccully@adobe.com> wrote:
>
> Checking if vert exists or not is too slow. We just set it on all upright
> characters.
>
> —Nat
> ------------------------------
> *From:* Shinyu Murakami <mshinyu@gmail.com>
> *Sent:* Friday, July 16, 2021 7:07:58 PM
> *To:* Nat McCully <nmccully@adobe.com>
> *Cc:* 木田泰夫 <kida@mac.com>; JLReq TF 日本語 <public-i18n-japanese@w3.org>
> *Subject:* Re: AJ1 (vert) と UAX#50 の食い違いの分析
>
> if vert exists →Yes→ "vert" glyph
>   ↓
>   No
>   ↓
>  "U"
>
> This behavior is good for "Tu" but not good for "Tr" (such as U+3030 WAVY
> DASH), so I think this should be:
>
> if vert exists →Yes→ "vert" glyph
>   ↓
>   No
>   ↓
> Is it "Tr"  →Yes→ Rotate the glyph
>   ↓
>   No
>   ↓
>  "U"
>
>
> ---
> Shinyu Murakami
>
>
> On Jul 17, 2021, at 10:38, Nat McCully <nmccully@adobe.com> wrote:
>
> 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?
>
> <スクリーンショット 2021-07-17 9.48.48.png>
>
> 2021/07/17 9:40、木田泰夫 <kida@mac.com>のメール:
>
> Correction: Please ignore the “No” after the “Apply vert” box.
>
> 2021/07/17 9:38、木田泰夫 <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>のメール:
>
> The logic is:
>
>
>    1. Use application logic or UTR#50 to determine if “R”
>       1. If “R”, rotate.
>       2. If not “R”, add vert and set upright.
>
>
> --Nat
>
>
> *From: *木田泰夫 <kida@mac.com>
> *Date: *Friday, July 16, 2021 at 5:10 PM
> *To: *JLReq TF 日本語 <public-i18n-japanese@w3.org>
> *Subject: *Re: AJ1 (vert) と UAX#50 の食い違いの分析
> 質問：「vert なし」の場合に縦になるか横になるかは、純粋にアプリケーションの動作に依存するという理解で正しいですか？
>
>
> 2021/07/16 20:30、木田泰夫 <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
>
> //
>
>
>
>
>
>
>
>