欧文泣き別れ
270 views
Skip to first unread message
Koji Ishii
Jun 20, 2012, 3:36:46 PM6/20/12
to epub-spec-...@googlegroups.com
欧文泣き別れについて質問です。
欧文泣き別れを設定した場合、記号の間でのラップは許されるべきですか？
●JLREQには記述が見当たらず（見落としてます？）
●IEはLetter間のみで、記号の間ではラップしない
●WebKitは記号間でもラップする
●Wordも記号間でもラップする
●今の仕様はIEベース、Letter/Number間のみ許す仕様
実は私の意識の中では、「記号間も許す」でした。仕様に「Letter/Number間のみ」と書いてあるのも知ってたのに、意識と仕様の差に今日まで気づかず…
記号・シンボル・絵文字などの間はword-break:break-allを設定してもラップ不可？
# そもそもデフォルトで絵文字間ではラップ不可、というのはちょっと驚きましたが
欧文泣き別れを設定した場合、記号の間でのラップは許されるべきですか？
●JLREQには記述が見当たらず（見落としてます？）
●IEはLetter間のみで、記号の間ではラップしない
●WebKitは記号間でもラップする
●Wordも記号間でもラップする
●今の仕様はIEベース、Letter/Number間のみ許す仕様
実は私の意識の中では、「記号間も許す」でした。仕様に「Letter/Number間のみ」と書いてあるのも知ってたのに、意識と仕様の差に今日まで気づかず…
記号・シンボル・絵文字などの間はword-break:break-allを設定してもラップ不可？
# そもそもデフォルトで絵文字間ではラップ不可、というのはちょっと驚きましたが
Kobayashi Toshi
Jun 20, 2012, 7:59:03 PM6/20/12
to epub-spec-...@googlegroups.com
石井 様
小林敏です
JLreqは，“附属書C 文字間での分割の可否”に示されています．前
が欧文用文字，後ろが欧文用文字の場合，その字間では分割不可で
す．そして，“附属書A 文字クラス一覧”に“欧文用文字”の一覧は示
されており，その中には記号や括弧類も含まれており，それらとの
字間では分割不可となります．簡単にいえば，分割したい場合は，
その字間にスペースを入れなさいということです．
例えば，終わり括弧類の後ろに欧文用文字が配置される場合，その
終わり括弧類が欧文用文字であれば分割不可となります（一般にはここには欧文用スペースが入るでしょうが，原稿では入っていない場合が多い）．終わり括弧類が文字クラスの“終わり括弧類”に含まれていれば分割可です．
もっとも，あくまで，JLreqは日本語組版の中に入る欧文用文字の
扱いということに限定されますが．
なお，10kmという数字と単位が組み合わさった場合，“10”と“kg”
の間で分割してよいかどうかは意見の分けれるところです．分割可
とする考えと，不可とする考えがあります．JLreqでは，“10”を連
数字，“kg”を単位記号として扱う場合は，分割可としています．
ここでも，記号やコンマ，ピリオド，括弧類などの前後で行の分割
を認めたい場合，欧文用スペースを入れる，ということが常識がど
うかだと思います．特に日本人の書く原稿では，日本語の部分での
コンマ，ピリオド，括弧類の前後にはスペースを入れないので，欧
文でのコンマ，ピリオド，括弧類の前後にもスペースを入れない原
稿をよくみかけます．また，これらが行中に来た場合，コンマ，ピ
リオド，括弧類の前後にスペースがないとおかしい，と私は思いま
すが，読めてしまうという現実もあります．
これを考えると，記号や約物の前後での分割とを認めてよいかどう
かが問題となるのでしょう．しかし，そこまで考える必要があるか
どうか，私は疑問に思いますが，どうでしょうか？
Koji Ishii さん wrote
小林敏です
JLreqは，“附属書C 文字間での分割の可否”に示されています．前
が欧文用文字，後ろが欧文用文字の場合，その字間では分割不可で
す．そして，“附属書A 文字クラス一覧”に“欧文用文字”の一覧は示
されており，その中には記号や括弧類も含まれており，それらとの
字間では分割不可となります．簡単にいえば，分割したい場合は，
その字間にスペースを入れなさいということです．
例えば，終わり括弧類の後ろに欧文用文字が配置される場合，その
終わり括弧類が欧文用文字であれば分割不可となります（一般にはここには欧文用スペースが入るでしょうが，原稿では入っていない場合が多い）．終わり括弧類が文字クラスの“終わり括弧類”に含まれていれば分割可です．
もっとも，あくまで，JLreqは日本語組版の中に入る欧文用文字の
扱いということに限定されますが．
なお，10kmという数字と単位が組み合わさった場合，“10”と“kg”
の間で分割してよいかどうかは意見の分けれるところです．分割可
とする考えと，不可とする考えがあります．JLreqでは，“10”を連
数字，“kg”を単位記号として扱う場合は，分割可としています．
ここでも，記号やコンマ，ピリオド，括弧類などの前後で行の分割
を認めたい場合，欧文用スペースを入れる，ということが常識がど
うかだと思います．特に日本人の書く原稿では，日本語の部分での
コンマ，ピリオド，括弧類の前後にはスペースを入れないので，欧
文でのコンマ，ピリオド，括弧類の前後にもスペースを入れない原
稿をよくみかけます．また，これらが行中に来た場合，コンマ，ピ
リオド，括弧類の前後にスペースがないとおかしい，と私は思いま
すが，読めてしまうという現実もあります．
これを考えると，記号や約物の前後での分割とを認めてよいかどう
かが問題となるのでしょう．しかし，そこまで考える必要があるか
どうか，私は疑問に思いますが，どうでしょうか？
Koji Ishii さん wrote
Koji Ishii
Jun 21, 2012, 4:44:20 PM6/21/12
to epub-spec-...@googlegroups.com
ありがとうございます。
> これを考えると，記号や約物の前後での分割とを認めてよいかどう
> かが問題となるのでしょう．しかし，そこまで考える必要があるか
> どうか，私は疑問に思いますが，どうでしょうか？
現在の仕様では、Unicode General Categoryで定めるLetterとNumberについてのみ挙動を変更する、と書いてありますので、今後test suitesが完成すれば、おそらくWebKitはバグとして登録されて、誰かが直さないとCSS3 Textの点数が低くなりますので、直していく可能性があります。
そういう意味では、決めないと困るし、決めて全部のブラウザーの挙動が揃った後で、「あ、こういうケースがあったからやっぱり」というのは困る、という話になりますので、それは将来の日本人のためにもきちんと決めてあげないといけないとは思っています。
もうひとつ気になるのは、これは「デフォルトの挙動から、LetterとNumberの間のみラップを許す」というものなので、そもそものデフォルトがどうなっているかによっても答えが変わる問題じゃないかと思います。小林先生はもちろんJLREQをベースにお話しされているんだと思いますが、ブラウザーはUAX#14などを実装して、そこからの変更になりますので、そこでじゃぁどれくらいの差があるのか、というのも気にしないといけない気がするんですが、ちょっとまだそこまで調べ切れておらず…
いくつか見えた範囲では、例えば＃、℡、数学記号類でJISにあるものなどはUAX#14によるとAI/ALで、Letter/Numberじゃないので、欧文泣き別れを設定しても改行が許されません。丸付き数字はNumberだけど丸付き英字はSymbolみたいですね。罫線文字、Unifiedされた記号類なども含まれるので、日本人の発想で「全角記号」とされるものは、改行できるものとできないものに分かれます。
ん～…どれも大きな問題ではないような気がしますが、逆にそもそも「英字と数字に限る」と限定している意味はあるんでしょうか？ 限定する必要がないならしない方が…と思いましたが、半角類で禁則を聞かせたい場合に、半角文字が禁則セットにきちんと入っていないと困りますね。それで困るくらいなら記号類が改行しないくらいはたいした問題じゃないか。
と、ちょっと行ったり来たりです。
禁則の問題は気になりますが、本来欧文泣き別れって、なるべくjustificationを減らしたいときに設定するものですよね？ 全角とされるものも含めて、記号の間が欧文泣き別れを設定しても分割不可でいいのかな、というところに少し引っかかります。
> これを考えると，記号や約物の前後での分割とを認めてよいかどう
> かが問題となるのでしょう．しかし，そこまで考える必要があるか
> どうか，私は疑問に思いますが，どうでしょうか？
そういう意味では、決めないと困るし、決めて全部のブラウザーの挙動が揃った後で、「あ、こういうケースがあったからやっぱり」というのは困る、という話になりますので、それは将来の日本人のためにもきちんと決めてあげないといけないとは思っています。
もうひとつ気になるのは、これは「デフォルトの挙動から、LetterとNumberの間のみラップを許す」というものなので、そもそものデフォルトがどうなっているかによっても答えが変わる問題じゃないかと思います。小林先生はもちろんJLREQをベースにお話しされているんだと思いますが、ブラウザーはUAX#14などを実装して、そこからの変更になりますので、そこでじゃぁどれくらいの差があるのか、というのも気にしないといけない気がするんですが、ちょっとまだそこまで調べ切れておらず…
いくつか見えた範囲では、例えば＃、℡、数学記号類でJISにあるものなどはUAX#14によるとAI/ALで、Letter/Numberじゃないので、欧文泣き別れを設定しても改行が許されません。丸付き数字はNumberだけど丸付き英字はSymbolみたいですね。罫線文字、Unifiedされた記号類なども含まれるので、日本人の発想で「全角記号」とされるものは、改行できるものとできないものに分かれます。
ん～…どれも大きな問題ではないような気がしますが、逆にそもそも「英字と数字に限る」と限定している意味はあるんでしょうか？ 限定する必要がないならしない方が…と思いましたが、半角類で禁則を聞かせたい場合に、半角文字が禁則セットにきちんと入っていないと困りますね。それで困るくらいなら記号類が改行しないくらいはたいした問題じゃないか。
と、ちょっと行ったり来たりです。
禁則の問題は気になりますが、本来欧文泣き別れって、なるべくjustificationを減らしたいときに設定するものですよね？ 全角とされるものも含めて、記号の間が欧文泣き別れを設定しても分割不可でいいのかな、というところに少し引っかかります。
Kobayashi Toshi
Jun 21, 2012, 7:46:33 PM6/21/12
to epub-spec-...@googlegroups.com
石井 様
小林敏です
word-break:break-allを設定しない場合と設定しない場合の差異が
よくわからないのですが，word-break:break-allでは，分割できる
範囲を最大にするという理解でいいのですか．
“LetterとNumberの間のみラップを許す”ということですが，コン
マやピリオドはletterに含まれるのですか．
例1） 123,456.789123
例2） 123 456.789 123
といった場合，コンマの後ろ，ピリオドの後ろで分割を認めるとい
うことでしょうか．この例1と例2（3桁ごとに四分空ける）でいえ
ば，分割できない，という考えと，分割できる，という考えがあ
り，word-break:break-allを設定すると両方とも分割できるという
ことでしょうか．なお，例2では，word-break:break-allを設定し
ない場合でも，分割されるのでしょうか（そうしてほしくない，と
いう考えはあります）．
近年は例が少なくなった（省略符が使われなくなった）が，
例3 U.S.A
は，分割してほしくないが，これもピリオドの後ろでも分割すると
いうことでしょうか．
“LetterとNumberの間のみラップを許す”ということであれば，Lett
erやNumberと，そうでないものが並んだ場合，ラップを許さない
ということですので，分割できる，という理解にはならないのでし
ょうか？
Koji Ishii さん wrote
小林敏です
word-break:break-allを設定しない場合と設定しない場合の差異が
よくわからないのですが，word-break:break-allでは，分割できる
範囲を最大にするという理解でいいのですか．
“LetterとNumberの間のみラップを許す”ということですが，コン
マやピリオドはletterに含まれるのですか．
例1） 123,456.789123
例2） 123 456.789 123
といった場合，コンマの後ろ，ピリオドの後ろで分割を認めるとい
うことでしょうか．この例1と例2（3桁ごとに四分空ける）でいえ
ば，分割できない，という考えと，分割できる，という考えがあ
り，word-break:break-allを設定すると両方とも分割できるという
ことでしょうか．なお，例2では，word-break:break-allを設定し
ない場合でも，分割されるのでしょうか（そうしてほしくない，と
いう考えはあります）．
近年は例が少なくなった（省略符が使われなくなった）が，
例3 U.S.A
は，分割してほしくないが，これもピリオドの後ろでも分割すると
いうことでしょうか．
“LetterとNumberの間のみラップを許す”ということであれば，Lett
erやNumberと，そうでないものが並んだ場合，ラップを許さない
ということですので，分割できる，という理解にはならないのでし
ょうか？
Koji Ishii さん wrote
Koji Ishii
Jun 21, 2012, 10:15:23 PM6/21/12
to epub-spec-...@googlegroups.com
On 2012/06/22, at 8:46, "Kobayashi Toshi" <bi...@k.email.ne.jp> wrote:
> 石井 様
>
> 小林敏です
>
> word-break:break-allを設定しない場合と設定しない場合の差異が
> よくわからないのですが，word-break:break-allでは，分割できる
> 範囲を最大にするという理解でいいのですか．
> “LetterとNumberの間のみラップを許す”ということですが，コン
> マやピリオドはletterに含まれるのですか．
含まれません。
> 例1） 123,456.789123
> 例2） 123 456.789 123
>
> といった場合，コンマの後ろ，ピリオドの後ろで分割を認めるとい
> うことでしょうか．この例1と例2（3桁ごとに四分空ける）でいえ
> ば，分割できない，という考えと，分割できる，という考えがあ
> り，word-break:break-allを設定すると両方とも分割できるという
> ことでしょうか．なお，例2では，word-break:break-allを設定し
> ない場合でも，分割されるのでしょうか（そうしてほしくない，と
> いう考えはあります）．
そして現在の仕様だと、break-all設定時には、数字間は分割可能になりますが、コンマやピリオドの前後は分割不可のままです。
> 近年は例が少なくなった（省略符が使われなくなった）が，
> 例3 U.S.A
> は，分割してほしくないが，これもピリオドの後ろでも分割すると
> いうことでしょうか．
> “LetterとNumberの間のみラップを許す”ということであれば，Lett
> erやNumberと，そうでないものが並んだ場合，ラップを許さない
> ということですので，分割できる，という理解にはならないのでし
> ょうか？
ラップ=分割ですので、ラップを許さない=分割不可になります。
Kobayashi Toshi
Jun 22, 2012, 12:25:40 AM6/22/12
to epub-spec-...@googlegroups.com
石井 様
小林敏です
分かりましたが，word-break:break-allで設定すると，
> > 例1） 123,456.789123
でいえば，“1”と“2”，“2”と“3”の字間は，分割可だが，“3”と“,”の
字間，“,”と“5”の字間では分割不可と理解してよい，ということで
すか．
例3 3rd
でいえば，どこでも分割可ということでしょうか．
もしそうであれば，このようなルールの組版は，使い道があるのか
な，という疑問が出てきます．原稿などや特別の場合で，とりあえず文字列が並んでいればよい，ということだと思います．そこで，少なくとも，行頭・行末禁則だけでも処理しようと，記号などとの分割を禁止したのでしょうが，特別な場合ですので，それも，あまり気にしなくてよいのではないかな．
なお，＃は，LJreqでは前置省略記号で，次にくるアラビア数字と
は分割禁止，数学記号の“－”は，文中で“は－3となる”といった場合
は，分割してほしくない．
といったように，個別に考えていけば，とても面倒だと思います
し，そのそも“3rd”が，どこでも分割してよい，アラビア数字がコンマ，ピリオド以外で分割できるのであれば，かなり特別な使用例なんだから，“－3”の字間で分割可でも不可でも，あるいは，その他の箇所で分割できようが，できまいが，あまり問題にならないのだと思いますが，どうでしょうか．
Koji Ishii さん wrote
小林敏です
分かりましたが，word-break:break-allで設定すると，
> > 例1） 123,456.789123
でいえば，“1”と“2”，“2”と“3”の字間は，分割可だが，“3”と“,”の
字間，“,”と“5”の字間では分割不可と理解してよい，ということで
すか．
例3 3rd
でいえば，どこでも分割可ということでしょうか．
もしそうであれば，このようなルールの組版は，使い道があるのか
な，という疑問が出てきます．原稿などや特別の場合で，とりあえず文字列が並んでいればよい，ということだと思います．そこで，少なくとも，行頭・行末禁則だけでも処理しようと，記号などとの分割を禁止したのでしょうが，特別な場合ですので，それも，あまり気にしなくてよいのではないかな．
なお，＃は，LJreqでは前置省略記号で，次にくるアラビア数字と
は分割禁止，数学記号の“－”は，文中で“は－3となる”といった場合
は，分割してほしくない．
といったように，個別に考えていけば，とても面倒だと思います
し，そのそも“3rd”が，どこでも分割してよい，アラビア数字がコンマ，ピリオド以外で分割できるのであれば，かなり特別な使用例なんだから，“－3”の字間で分割可でも不可でも，あるいは，その他の箇所で分割できようが，できまいが，あまり問題にならないのだと思いますが，どうでしょうか．
Koji Ishii さん wrote
Kobayashi Toshi
Jun 23, 2012, 6:21:45 PM6/23/12
to epub-spec-...@googlegroups.com
石井 様
小林敏です
"欧文泣き別れ"の前のメールに，少し補足しておきます．
word-break:break-allを設定した場合は，語の分割を認めるわけで
すから，特別の目的があるか，特別な事情があるからだと思いま
す．後者の例としては，表の小間などのように，行長がとても短い
場合などに利用できるということだと思います．justificationをし
ないとしても，どうしようもない場合があります．つまり，応急処
置的に，ある限られた目的に使用するものだと思います．
次に，word-break:break-allを設定した場合は，欧文だけのとき
は，それなりにうまくいくだろうと思います．確かに，アラビア数
字の中にコンマ，ピリオドがあった場合には，少々問題です．ま
た，USAでは字間で分割でき，U.S.A.ではできないというのも少々
おかしいと思います．しかし，後者の例は，省略符のピリオドは使
わない傾向ですので，今後の使用例はほとんどなくなるでしょう．
"H. C. Andersen"という例では，ピリオドの後ろには語間スペースが入るか，又はピリオドを省略するでしょう．その他，約物で前後がベタになる例では，
…… ed.,
aaaaa,"
などがありますが，これらはdやaの後ろ，ピリオドやコンマの後ろ
で分割しないことが望ましい処理です．
また，数学記号など記号では，欧文組版では，分割したくなければ
ベタにし，分割したい場合は語間スペースを入れるでしょう．分割
したくない箇所であれば，word-break:break-allで，分割できなく
ても，応急処置的な処理なんだから，それほど問題はでないと考え
てもよいでしょう．
欧文では，分割箇所は，原則として語間スペースが入っていると考
えてよいからです．そして，少々問題がでる例もあるが，多くの場
合において，約物の前後を分割禁止にすれば，行頭禁則，行末禁則
が解決できます．
このように，欧文では分割箇所には原則として語間スペースが入る
のに対し，日本語組版のようにベタ組が原則の場合とでは，異なっ
てくるでしょう．日本語組版では，word-break:break-allを設定し
た場合，より問題が出てくる可能性が高くなるということだと思い
ます．つまり，word-break:break-allを設定しない場合でも分割で
きる箇所が，word-break:break-allを設定すると分割できなくなる
可能性がある，という問題です．
しかし，前述したように，word-break:break-allは，ある限られた
条件では，それなりに機能するわけだということ，そして，日本語
との混ぜ組で，word-break:break-allを使用する場合も，ある限ら
れた条件で使用するわけですから，問題点を心得て使用すればよい
ことだと思います．
逆な，言い方をすれば，そのようなケースで問題点がでないような
解決策を検討することは否定しませんが，優先順位は，かなり低い
のではないか，ということだと思います．
小林敏です
"欧文泣き別れ"の前のメールに，少し補足しておきます．
word-break:break-allを設定した場合は，語の分割を認めるわけで
すから，特別の目的があるか，特別な事情があるからだと思いま
す．後者の例としては，表の小間などのように，行長がとても短い
場合などに利用できるということだと思います．justificationをし
ないとしても，どうしようもない場合があります．つまり，応急処
置的に，ある限られた目的に使用するものだと思います．
次に，word-break:break-allを設定した場合は，欧文だけのとき
は，それなりにうまくいくだろうと思います．確かに，アラビア数
字の中にコンマ，ピリオドがあった場合には，少々問題です．ま
た，USAでは字間で分割でき，U.S.A.ではできないというのも少々
おかしいと思います．しかし，後者の例は，省略符のピリオドは使
わない傾向ですので，今後の使用例はほとんどなくなるでしょう．
"H. C. Andersen"という例では，ピリオドの後ろには語間スペースが入るか，又はピリオドを省略するでしょう．その他，約物で前後がベタになる例では，
…… ed.,
aaaaa,"
などがありますが，これらはdやaの後ろ，ピリオドやコンマの後ろ
で分割しないことが望ましい処理です．
また，数学記号など記号では，欧文組版では，分割したくなければ
ベタにし，分割したい場合は語間スペースを入れるでしょう．分割
したくない箇所であれば，word-break:break-allで，分割できなく
ても，応急処置的な処理なんだから，それほど問題はでないと考え
てもよいでしょう．
欧文では，分割箇所は，原則として語間スペースが入っていると考
えてよいからです．そして，少々問題がでる例もあるが，多くの場
合において，約物の前後を分割禁止にすれば，行頭禁則，行末禁則
が解決できます．
このように，欧文では分割箇所には原則として語間スペースが入る
のに対し，日本語組版のようにベタ組が原則の場合とでは，異なっ
てくるでしょう．日本語組版では，word-break:break-allを設定し
た場合，より問題が出てくる可能性が高くなるということだと思い
ます．つまり，word-break:break-allを設定しない場合でも分割で
きる箇所が，word-break:break-allを設定すると分割できなくなる
可能性がある，という問題です．
しかし，前述したように，word-break:break-allは，ある限られた
条件では，それなりに機能するわけだということ，そして，日本語
との混ぜ組で，word-break:break-allを使用する場合も，ある限ら
れた条件で使用するわけですから，問題点を心得て使用すればよい
ことだと思います．
逆な，言い方をすれば，そのようなケースで問題点がでないような
解決策を検討することは否定しませんが，優先順位は，かなり低い
のではないか，ということだと思います．
Koji Ishii
Jun 25, 2012, 5:54:12 AM6/25/12
to epub-spec-...@googlegroups.com
> つまり，応急処置的に，ある限られた目的に使用するものだと思います．
正否は置いておいて、少なくとも現場的にはもうちょっと違うイメージでとらえられているように見えます。ChromeやSafariなどのWebKitブラウザーで開いてもらえば禁則が壊れるので分かりますが、先日のアゴラだけでなくtogetter.comでも本文に使っています。一、二週に一回くらいはそういうページに遭遇するくらいの頻度のイメージを持っています。
私も基本優先順位が低くてよいとは思っているのですが、想定外の使い方をしているページが結構あること、InDesignの欧文泣き別れはバージョンアップでロジックが変わったり結構色々な意見が飛び交っているので意外に印刷屋さんの関心が高そうであること、そろそろLCに持っていきたいCSS Text Level 3に入っていることから、「それでいいのかな」という漠然とした懸念を持っている、という状況です。
例えば縦書きでcaféを正立にしたいとします。これも賛否両論あるでしょうが、正立欧文は漢字と同じ分割とする考え方で行くと、é=U+00E9には全角文字がありませんので、書式として正立させることになりますが、é=U+00E9はUnicode属性的には欧文なので、和文の扱いをするにはbreak-allを使うことになります。é=U+00E9はLetterなので今の仕様で問題ありませんが、全角のないunified記号は今後和記号として扱うことができなくなります。
それがどういうユースケースがあって、どれくらい問題なのか、というところまでは恥ずかしながらまだ考えが及んでおりません。考えをまとめていくにあたって、印刷で言われる「欧文泣き別れ」はどういうもので、例えばInDesignはどう実装していて、というのを勉強しようかと思いつつ、ちょっと進捗が…
ご教示いただいたことを併せ考えて、小林先生がおっしゃられているように下手に記号も含めて分割可にしてしまうと
このMLで誰も予見できないくらいの問題であれば、とりあえずそれでよさそうな気がしてきました。ありがとうございます。
正否は置いておいて、少なくとも現場的にはもうちょっと違うイメージでとらえられているように見えます。ChromeやSafariなどのWebKitブラウザーで開いてもらえば禁則が壊れるので分かりますが、先日のアゴラだけでなくtogetter.comでも本文に使っています。一、二週に一回くらいはそういうページに遭遇するくらいの頻度のイメージを持っています。
私も基本優先順位が低くてよいとは思っているのですが、想定外の使い方をしているページが結構あること、InDesignの欧文泣き別れはバージョンアップでロジックが変わったり結構色々な意見が飛び交っているので意外に印刷屋さんの関心が高そうであること、そろそろLCに持っていきたいCSS Text Level 3に入っていることから、「それでいいのかな」という漠然とした懸念を持っている、という状況です。
例えば縦書きでcaféを正立にしたいとします。これも賛否両論あるでしょうが、正立欧文は漢字と同じ分割とする考え方で行くと、é=U+00E9には全角文字がありませんので、書式として正立させることになりますが、é=U+00E9はUnicode属性的には欧文なので、和文の扱いをするにはbreak-allを使うことになります。é=U+00E9はLetterなので今の仕様で問題ありませんが、全角のないunified記号は今後和記号として扱うことができなくなります。
それがどういうユースケースがあって、どれくらい問題なのか、というところまでは恥ずかしながらまだ考えが及んでおりません。考えをまとめていくにあたって、印刷で言われる「欧文泣き別れ」はどういうもので、例えばInDesignはどう実装していて、というのを勉強しようかと思いつつ、ちょっと進捗が…
ご教示いただいたことを併せ考えて、小林先生がおっしゃられているように下手に記号も含めて分割可にしてしまうと
> 日本語組版では，word-break:break-allを設定し
> た場合，より問題が出てくる可能性が高くなるということだと思い
> ます．つまり，word-break:break-allを設定しない場合でも分割で
> きる箇所が，word-break:break-allを設定すると分割できなくなる
> 可能性がある，という問題です．
のリスクが高まりますので、きちんと手が回らないなら現行のままLetter/Numberのみにしておいて「123,456.789」のケースは目を瞑り、問題があるなら制作者から上がってくるのを待ってみるのがいいかと思っています。
> た場合，より問題が出てくる可能性が高くなるということだと思い
> ます．つまり，word-break:break-allを設定しない場合でも分割で
> きる箇所が，word-break:break-allを設定すると分割できなくなる
> 可能性がある，という問題です．
このMLで誰も予見できないくらいの問題であれば、とりあえずそれでよさそうな気がしてきました。ありがとうございます。
Reply all
Reply to author
Forward
0 new messages