- From: 田嶋 淳 <tajima@sanyosha.co.jp>
- Date: Thu, 17 Dec 2020 09:59:36 +0900
- To: Yasuo Kida <kida@mac.com>
- Cc: JLReq TF 日本語 <public-i18n-japanese@w3.org>
- Message-Id: <3C421BFC-B46E-4151-904F-29F86BBE252B@sanyosha.co.jp>
木田さま みなさま 追加です。「そういえばキリル文字が地雷だった」ことを思い出したのでちょっと見てみたのですが、Natさんの資料見てみるとInDesignで和文フォントを使った際のU+0400から始まるキリル文字の縦書き時の挙動があらためて面白いですね。どうやらShift_JISの時代からあった文字は「U」で、後から加えられた文字が「R」扱いのようです。なおUAX#50ではまとめて「R」なので、挙動の違いがあります。 キリル文字はKindleがこれまでずっと全文字正立の挙動で、text-orientationも効かないため単語ごとに外字にして並べざるを得なくなるなどずいぶん大変でした。Kindle Previerer3の表示を見る限りでは今はtext-orientationは効くようになったのかなと思っていますが、デフォルトの正立横転の挙動はまだ未確認です。 > 2020/12/16 17:24、田嶋 淳 <tajima@sanyosha.co.jp>のメール: > > 木田さま > みなさま > >> ・電子書籍化において例えば縦書きに現れる割り算記号は縦横方向に気をつける必要がある(田嶋) > > 今ちょっとNatさんの資料とUAX#50の該当部分を見てみたのですが、どちらも「U」で、そこに差はないようです。ただ、ちょっと前までUAX#50の通りの挙動を示さないビューアはたくさんあったように思いますし、おそらく今でも残っているでしょう。また、縦書きで横転させたい時に、text-orientation:sideways の指定が効かないEPUBビューアは観測範囲にたくさんありました。横転している約物を正立させるのなら text-combine-upright に逃げられますが、正立している約物の横転はどうにもならなかったりしたわけです。 > おそらくこういう記号文字は除算記号に限らずいくらもあるのですが、比較的よく出てくるため目立ったということと思います。 > >> 2020/12/16 16:34、木田泰夫 <kida@mac.com <mailto:kida@mac.com>>のメール: >> >> みなさま、 >> >> 今日のミーティングは白熱しましたね! この議論をきっかけにして行き着く先が楽しみです。ノートをまとめてみました。抜け、訂正の必要があったら教えてください。修正ののち英語版を作ります。いくつか質問もあります。 >> >> >> cl-15/16 ひらがな、カタカナ >> ・変体仮名や仮名の合字→このクラスに含める(U+309F こと→ cl-19 から cl-15 へ、U+30FF より cl-19 から cl-16 へ、Unicode で変体仮名や仮名の合字が加えられている。それらもここ)。濁点半濁点合成の文字もここ(すでにそうなっているが念の為)。enclosed circle が加わるのは別(cl-19) >> ・漢字との違いはルビがかかるかどうか(木田質問:つまり、字間のためだけなら特に別クラスにする必要は特にないということ?) >> >> cl-17/18 等号類、演算記号 >> ・cl-17, cl-18 は整理し直す。日本語の縦組みコンテキストで日本語の一部として使われる文字のみ、例えば+-など、を拾い上げてそれらの挙動を記述する(クラスが残るかどうか不明)。その他の文字は JLReq 担当外。例えば数学専用の文字組みルールに任せる。 >> >> >> >> 議論 >> >> 縦書きにおける記号の正立回転問題 >> 色々な議論がありましたが、一つの総意は、Unicode 上で分けるべき文字がありそう、ということかと思います。 >> ・記号は unify しすぎ。別個のコードポイントが必要。例:長音 wave dash、三点リーダ(小林)、三点リーダ、スマートクオート=左右別々のもの e.g. U+2019(Nat) >> ・縦横の動きが異なるなら分けた方が良い(小林、Nat)。InDesign で UR のもの、別コードポイントが欲しい(Nat) >> ・X0213で追加された二重ハイフンの利用が進んでいない(小林)(これは何が問題で何がゴール?) >> ・ハイフンと二分ダーシ(及び二重ハイフン/二分二重ハイフン/イコール?)が混用されている。意味とデザインが違うので使い分けが好ましい。動作は JLReq では両方とも行頭禁止(敏先生) >> ・電子書籍化において例えば縦書きに現れる割り算記号は縦横方向に気をつける必要がある(田嶋) >> (木田質問:これは、意識しないと回転するが、正立で必要な場合がある、というお話でしたっけ) >> ・FFxx だけ別クラスにして、例外なく正立にすれば良いのでは(小林)(木田:現在 UAX 50 において、全角互換文字のうち “<=>-” の4文字が R、つまり縦書きで回転する規定になっている)。全角 “+” が回転から外れているが、問題がある。縦横でストローク幅を変えてある例などあるので(敏先生) >> ・全角グリフの違いは、幅が全角かどうか、だけではなく、中心線に揃っているか(敏先生) >> ・縦組みでの記号の正立回転挙動について例を調べたい(小林)国語研のことのはコーパスは使えるか?(木田)ブルーバックスが科学技術系なのに縦書き(小林)良いサンプルになりそう(木田) >> ・プレーンテキストで指定する方法は入力し次第反映され、またプレーンテキストでも動くので、後でマークアップする方法に比べユーザビリティに優れる(木田) >> ・Unicode に正立か横組みかを指定する仕組みを作るのはどうか。bidi 制御文字のように(村上)そのために variation selector を使うのはどうか(小林) >> ・Hyphen-Minus やクオートとアポストロフィの例のように、タイプライター、7bit ascii、8 bit ascii など昔の限られた環境で同じだったものが、Unicode で意味的、機能的に分けることができるようになった(小林など) >> >> >> そのほか >> ・議論から、「その文字そのものについて述べている文脈」は除く。その議論を含めてしまうと全ての文字が縦書きで正立すべきという議論になる(木田)。また、デフォルト動作を決めているのであってマークアップで変更可能、という意識が必要。こういう場合もある、ではなくこういう場合が多い、という意識(木田) >> ・CJK ideograph 過剰に un-unified されている。それらの文字の使用を制限したい(小林)。制限は難しく normalization で対処すべきでは(木田) >> ・この文字は日本語で使われている、と文字を抜き出すことには危険性もある。例えば JIS は ¥$ を採用したが、Unicode にはさまざまな国の通貨記号が含まれている。これらは縦書きでどう挙動するのか。拡張可能な仕組みが必要(木田) >> ・この記号の整理、どのくらい時間をかけるつもり?(小林)半年くらい?(木田 :) >> >> >> 次回は1月26日火曜日 >> >> 木田 >> > > *************************************** > (株)三陽社 > メディア開発室 > http://www.sanyosha.co.jp/ <http://www.sanyosha.co.jp/> > > 田嶋 淳 > tajima@sanyosha.co.jp <mailto:tajima@sanyosha.co.jp> > > ※ブログ運営中です。 > ご意見をいただければ幸いです。 > http://densyodamasii.com/ <http://densyodamasii.com/> > *************************************** > *************************************** (株)三陽社 メディア開発室 http://www.sanyosha.co.jp/ 田嶋 淳 tajima@sanyosha.co.jp ※ブログ運営中です。 ご意見をいただければ幸いです。 http://densyodamasii.com/ ***************************************
Received on Thursday, 17 December 2020 00:59:55 UTC