- From: Shinyu MURAKAMI <murakami@vivliostyle.org>
- Date: Sun, 25 Sep 2022 17:15:23 +0900
- To: "Atsushi Shimono (W3C Team)" <atsushi@w3.org>
- Cc: public-i18n-japanese@w3.org
- Message-Id: <5D4D5475-A017-446A-929F-C01FF352AA54@vivliostyle.org>
村上です。 全角と非全角の約物が隣接するケースのテストサンプルを作ってみました。 https://murakamishinyu.github.io/bugtest/text-spacing/trim-ajacent.html <https://murakamishinyu.github.io/bugtest/text-spacing/trim-ajacent.html> 次のサンプルテキストについて、text-spacing: none の場合と text-spacing: normal の場合とをテストするものです。 (「全角の括弧」で囲まれている。)「括弧が隣接」(全角の括弧) [「プロポーショナルな括弧」で囲まれている。]「括弧が隣接」[プロポーショナルな括弧] “「ダブルクォーテーション」で囲まれている。”「括弧が隣接」“ダブルクォーテーション” ༺「チベット語の括弧」で囲まれている。༻「括弧が隣接」༺チベット語の括弧༻ 現状のブラウザではtext-spacingは機能しないので約物の隣接は何も処理されません。 Vivliostyle Viewer(ブラウザにCSS組版機能を拡張)でこのテストサンプルでの約物の隣接の処理を確認できます: https://vivliostyle.vercel.app/#src=https://murakamishinyu.github.io/bugtest/text-spacing/trim-ajacent.html <https://vivliostyle.vercel.app/#src=https://murakamishinyu.github.io/bugtest/text-spacing/trim-ajacent.html> スクリーンショット: text-spacing有効(normal)の場合、開き約物どうしが隣接、および閉じ約物どうしが隣接の場合では、外側の括弧類が全角か非全角かは関係なく、内側のもともと全角幅の約物の2分のアキは詰められます。 また、閉じ約物と開き約物とが隣接する場合は、一方が非全角の場合にはもう一方の全角幅を保持します。(実は昨日これをテストしたとき、必ずしもこのとおりになっていないバグ <https://github.com/vivliostyle/vivliostyle.js/issues/1003>があるの気がつき修正しました) 全角か非全角かは関係なく開き、あるいは閉じの約物かという判定は、Unicodeのカテゴリが PsかPiなら開き、PeかPfなら閉じとしています。PiとPf(欧文引用符など)については、言語によって開きと閉じが逆になるのですが、全角約物との隣接でそれが問題になるケースはあまりないだろうからこれで十分という判断です(lang属性によってPiとPfの扱いが変わるようにするとよりよいかもしれません)。 参考まで。 Vivliostyle村上 > On Sep 24, 2022, at 1:14, Atsushi Shimono (W3C Team) <atsushi@w3.org> wrote: > > > > On 2022/09/23 10:09, Yasuo Kida wrote: >> 元のバグにはコメントを入れておきました。 >> https://github.com/w3c/csswg-drafts/issues/6091 <https://github.com/w3c/csswg-drafts/issues/6091> > > m__m > > # 後はフルパッケージできれば持って行ってすり合わせ、ですかね?とはいえ、EAW=F/Wの中の > spacingを調整する点だけなのでCJ(K?)の間だけだとは思いますが? > >>> 2022/09/23 2:26、Atsushi Shimono (W3C Team) <atsushi@w3.org>のメール: >>>> 下に記録しました。 >>>> https://github.com/w3c/jlreq-d/issues/24 <https://github.com/w3c/jlreq-d/issues/24> >>>> またこれに対して Unicode 拡張字間クラスのドキュメントのレビューを行い、必要ならアップデートします >>>> https://github.com/w3c/jlreq/issues/340 <https://github.com/w3c/jlreq/issues/340> >>> >>> Unicodeベースの文字クラスを見たところ、基本的にEAW=W/FでフィルターしたうえでのGeneral >>> Categoryなどで文字クラスを定義していました。e.g. >>>> 前に空間を必要とする約物:始め括弧類の拡張 >>>> 普通の全角かつ General Category = Ps (Open_Punctuation: an opening punctuation mark (of a pair)) >>> >>> ということで、EAW != W/Fのものと隣接した場合の条件を追加すると大体は解決できそうな気は >>> しました。 >> ありがとうございます! それで行きましょう。 >>> 問題としてはU+0F3A (TIBETAN MARK GUG RTAGS GYON, Open_Punctuation)とかの今の議 >>> 論で想定外のものが多数紛れ込んでくる、ということがあるかもしれませんが、、非常にレアケー >>> スでしょうし、。 >>> とはいえ、中にspacingを含んでいない1emでない狭い文字の場合はいいとして、1emに近い文字 >>> の場合は何かしら検討しないといけない、、のかな?とも思うところではありますが。。 >> シンプルさを保ちましょう。プライオリティも低いですし。 > > +1 > まぁ、元が空き過ぎのspacingを取り去る、ですので、spacingを取り去ってしまえ、という話からす > ると、敏先生のケース1-3の分類にそう、であってそうですよね。。 > # あ、1-3にない中黒みたいな両側に0.25ずつ空間があるものについては、EAW=F/Wについては0.5+0.25 > から-0.5で0.25残りますが、これも特に変わらず、ですかね?Terminal_Punctuationにしか該当の文字 > は出現しませんが。 > https://util.unicode.org/UnicodeJsps/list-unicodeset.jsp?a=%5B%5B%3Aterminal_punctuation%3A%5D%26+%5B%3AEast_Asian_Width+%21%3D+Wide+%3A%5D%26+%5B%3AEast_Asian_Width+%21%3D+Fullwidth+%3A%5D+%5D&g=&i= > (Other_Punctuation & :Hyphen:は半角中黒のみ) > >> と言いつつチベット語開き括弧の実際の使用例を探してみたのですが、10分間では見つけられませんでした。Wikipedia <https://bo.wikipedia.org/wiki/%E0%BD%82%E0%BD%A6%E0%BD%A2%E0%BC%8B%E0%BD%96%E0%BE%B1%E0%BD%B4%E0%BD%84%E0%BC%8B%E0%BD%82%E0%BD%B2%E0%BC%8B%E0%BD%82%E0%BD%93%E0%BD%A6%E0%BC%8B%E0%BD%9A%E0%BD%B4%E0%BD%A3%E0%BC%8D>とかここ <https://bod-rangzen.org>とかここ <https://bodyiglobjong.com>。ということはチベット語の中でも、webでの使用ではとの条件付きですが、この括弧の使用は一般的ではない可能性がありますね。 >> それにしてもこの括弧は孫悟空の筋斗雲みたいで華麗ですね。日本語と組み合わせてもいい感じです。 >> ༺筋斗雲༻ >> ༺なんたらかんたら༻ >> ༺(全角約物との組み合わせ)༻ >> ༺「全角約物との組み合わせ。༻ > > ;) > # なんかアスキーアートとかtwitterとかでもすでに使われてそうな感じですね、、、 > >>> というところまで考えてきて、ふと思ったのですが、敏先生の分類の「特別な処理は不要」なも >>> ので、文字サイズが異なる約物の連続: >>> https://github.com/w3c/jlreq/blob/gh-pages/docs/layout_of_punctuations/punctuations_in_different_sizes.md >>> に該当する場合、こちらに例外規定を入れないといけない?もしくはどのやり方を選ぶかが変わる >>> しかない?事例が出そうな気がしました。。。 >>> # パッチワークをやり始めると破綻に近づいていくといういい事例なのかもしれませんが・・・>< >> これもシンプルにしましょう。何かの対処が必要と思われる具体的なケースってあります? > > いろいろ考えていたのですが、敏先生のおっしゃる通り、ケース1の」「の場合のケース位でしょうか。。 > まぁ、といって、同じく別メールでおっしゃるように、5つの処理パターンの中での選択が違ってくる > だけ、と思えば、崩れるほどのものではない、のかもしれませんが、、、 > # 個人的にそこまでspacingサイズにこだわらなくても、と思ってしまうという感覚のなさかもしれませ > んけれども・・・ > > あ、中黒みたいなものの処理について、両側の括弧類から-0.5するという(EAW!=F/Wなのが来た場合 > は両側とも完全ベタ)のでよければ、他に考慮することはない、でしょうか・・・ > > > ひとまず、そろそろ整理がつけられそうではあるので、次は > https://github.com/w3c/jlreq/blob/gh-pages/docs/spacing_property/spacing_property.md#%E6%96%87%E5%AD%97%E9%96%93%E3%81%AE%E7%A9%BA%E3%81%8D%E9%87%8F%E3%81%AE%E8%A1%A8 > の表に追記していく作業、でしょうか?? > >
Attachments
- text/html attachment: stored
- image/png attachment: text-spacing-trim-adjacent-test-result.png
Received on Sunday, 25 September 2022 08:15:44 UTC