- From: 木田泰夫 <kida@mac.com>
- Date: Wed, 29 Apr 2020 12:02:57 +0900
- To: Koji Ishii <kojii@chromium.org>
- Cc: public-i18n-japanese@w3.org
Received on Wednesday, 29 April 2020 03:03:13 UTC
> 2020/04/29 11:25、Koji Ishii <kojii@chromium.org>のメール: > > すみません、昨夜読んだ時には誤解していたような気がします。 > > 2020年4月28日(火) 20:43 木田泰夫 <kida@mac.com <mailto:kida@mac.com>>: > で、和欧文間の空きにどう関わってくるかというと、ここの空間を空白文字を使って記述してもいいのではと。一般的な空白文字は、欧文書体を見ると、例えば Helvetica で同じサイズの和文全角と比べて三分くらい。広すぎるのですが、それこそ、空白の幅を CSS で調節すれば良いのですよ。空白文字がない場合の調節はすでに記述されていますよね。あってもなくても同じ結果。だって同じことを達成するのに違う言葉を使っているだけなんですから。 > > 荒削りですが、こんな方向。どうでしょう? > > 「空白文字を入れず、和字と欧字の間にアキを入れる」という概念と > 「空白文字を入れて、その前後が和字と欧字だったら、空白の幅を調整する」という概念 > の違い、という意味ですか? はい、その通り! > それはありだと思いますが、segment transfomation ruleとのかかわりがよく見えません。もう少しご説明いただけると。 現在の Segment Break Transformation Rules では、ここに空白文字が入ります。しかるに、JLReq はここに空白文字を期待していません。その齟齬は、JLReq と欧文組版の、空間を開けたいときにそれを implement する方法の違い、というもっと深いところに根差しています。その違いが JLReq と国際化環境との互換性を悪くしています。Segment Break Transformation Rules がどうのというより、その互換性を悪くするアーキテクチャの違いを解消したい、というのが意図です。実際に見た目上で開けるかどうかは別問題というわけ。 木田
Received on Wednesday, 29 April 2020 03:03:13 UTC