- From: 木田泰夫 <kida@mac.com>
- Date: Sat, 9 May 2020 08:10:47 +0900
- To: 下農 <atsushi@w3.org>
- Cc: public-i18n-japanese@w3.org
- Message-Id: <76285B09-926A-4CE4-8BBB-816A11E1057E@mac.com>
将来の話は置いておいて、今日明日の問題に対処しなくてはね。下農さんありがとう。 インラインで(そもそもの背景を一番後ろに付けておきました): > 2020/05/08 16:30、Atsushi Shimono (W3C) <atsushi@w3.org>のメール: > > (純粋にfyiです > > こちら、clreqで(も?)議論があり、 > https://github.com/w3c/clreq/issues/293 <https://github.com/w3c/clreq/issues/293> > [w3c/clreq] Space between characters after joining two lines (#293) > https://www.w3.org/2020/05/07-clreq-minutes.html#t08 <https://www.w3.org/2020/05/07-clreq-minutes.html#t08> > > our consensus was that Bopomofo should not discard spaces because spaces are sometimes used in Bopomofo-only text. > だそうでした。 日本語も文字種ごとにそれで良いか考える必要がありますね。どんな文字種間が問題になりそうでしょう? ・和字とアルファベットなどスペースで区切るスクリプトとの間 ・和字かどうか曖昧なもの(EAW=Ambiguous*):囲み数字、単位記号、絵文字、 他に何がありますっけ? JLReq の文字クラス <https://www.w3.org/TR/jlreq/ja/#character_classes>と space-discarding character set <https://drafts.csswg.org/css-text-3/#space-discard-set> を比べると良さそうですね。スクリプトを書いて自動的にチェックできるといいんだけど。 … やってみるか github issue 作りました https://github.com/w3c/jlreq/issues/211 <https://github.com/w3c/jlreq/issues/211> >> ・幅が狭いZsの文字を入れまくる処理はめんどくさくてやりたくないが全部U+0020 (1/2em)より細いspacingにしたい宗派 >> の組み合わせが一番不満を抱くのかな、と思うのです。また、もちろん、空きを入れない宗派もある程度困ると >> 表明するでしょうけれど。。というところで、追加としてもあまり複雑にならない程度で行くことを想定するな >> らば、white-spaceにアグレッシブに空白除去するモードがあってもいいのかな、と思ったりするのです。 >> 多分、前述の2つ目の宗派はいまのwhite space除去規則の中でのU+0020を除去する処理(約物かP*/S*、F/H/Wide >> の2つが両側に連なるsegment breakは除去)でだいたい満足しているのかな、と思うところですので。。 >> # この両側の制限が本当にいいのかはもちとじっくり考えてみたいところですが、、。 >> いかがでしょうか、、 > > # call/issueでなくメールでの議論が主になってる現状で、特に敏先生のまとめとか議論サマリーを英語で > どっかに蓄積しないとなぁ、とは思いつつ、、個別スレッドをissueに乗っけるのもまたいろいろ混じって違 > う話になるし、ともにょもにょしているのですが、、 > github repositoryのwikiに突っ込んでいくとかどうで > すかね、、。本当はcodeの中にmarkdownとかでテキストファイルを蓄積していくのがいいのでしょうけれど、 > もろもろ(?)始めるまでが面倒感。。 確かに。敏先生のまとめはどこかに蓄積したいですね。その度に英訳するのは面倒ですが、少なくともサマリーを英語でつけるとか。wiki が手間が少なさそうです? また、このメーリングリストはフリーディスカッションのために良いのですが、適宜情報を jlreq github の方に移すべきですね。それを忘れちゃいけない。けど忘れがち… 木田 –––––––––––––– 背景(Segment Break Transformation Rules) > Segment Break Transformation Rules って何? をちょっと説明すると、CSS にはバラバラの行に分割して書かれたテキストを繋げ直して表示する機能があります。下のように改行をどんどん入れて書いても、ちゃんと一つながりの文にしてくれます。 > ––––––– > Here is an English paragraph > that is broken into multiple lines > in the source code so that it can > more easily read in a text editor. > ↓ ↓ ↓ > Here is an English paragraph that is broken into multiple lines in the source code so that it can be more easily read in a text editor. > ––––––– > > 改行を空白文字に置き換える動作は日本語や中国語では困ります。ので、簡単にいうと改行文字の「両方」が全角文字なら、空白を入れないことになっています。 > ––––––– > 春はあけぼ > の。ようよ > う白くなり > ゆくやま > … > ↓ ↓ ↓ > 春はあけぼの。ようよう白くなりゆくやま… > ––––––– > > こんなことの詳細を決めているのが、Segment Break Transformation Rules です。正確なルールは CSS Text Level 3、また、このルールを適用する文字のリスト(2番目のリンク)を参照してください。 > https://www.w3.org/TR/css-text-3/#line-break-transform <https://www.w3.org/TR/css-text-3/#line-break-transform> > https://drafts.csswg.org/css-text-3/#space-discard-set <https://drafts.csswg.org/css-text-3/#space-discard-set> > > さて、議論が起きているのは、囲み数字などはどうするの?和文欧文両方で使う文字はどうする(EAW=Ambiguous)? などの詳細です。 > https://github.com/w3c/csswg-drafts/issues/4992 <https://github.com/w3c/csswg-drafts/issues/4992> > https://github.com/w3c/clreq/issues/293 <https://github.com/w3c/clreq/issues/293> > https://github.com/w3c/csswg-drafts/issues/337 <https://github.com/w3c/csswg-drafts/issues/337> > > それも重要なのですが、私が気になったのは、改行文字の「両方」が全角文字、という条件です。このルールで例えば和字の中に英字があった場合、和字と英字の間に空白(U+0020)が挿入されます。 > ––––––– > 春はあけぼ > のがnice > ですって。 > ↓ ↓ ↓ > 春はあけぼのがnice ですって。 > –––––––
Received on Friday, 8 May 2020 23:11:05 UTC