* 仕様書 [REFS[ - [18] [CITE[The Unicode Standard, Version 13.0 - ch23.pdf]], [TIME[2020-03-09T17:53:52.000Z]], [TIME[2020-12-09T10:59:29.820Z]] ]REFS] * 意味 [5] [CODE(char)[U+00AD]] [CODE(charname)@en[SOFT HYPHEN]] ([CODE(charname)@en[SHY]]) は、 [RUBYB[[[語]]中][intraword]]の[RUBYB[分断点][break point]]であって、 [[語]]が[[ハイフン付け]]その他[[行]]にわたって分割されるときに[[改行]]するのに[RUBYB[好ましい][preferred]]位置を示します。 [SRC[>>18]] [6] そうした分断点は、 通常は自動化された[[ハイフン付け器]]によって決定します。 [SRC[>>18]] [7] [CODE(charname)@en[SHY]] は任意の[[用字系]]で使うことができますが、 通常は自動化された[[ハイフン付け器]]の挙動を[[利用者]]が上書きする必要がある状況に限って使います。 [SRC[>>18]] * レンダリング [8] 語中の分断点での [[line break]] の可視的な[[レンダリング]]は、 自動的に決定されたものにせよ、 [CODE(charname)@en[SHY]] により示されたものにせよ、 周りの[[文字]]、 [[用字系]]や[[言語]]の規則、 [[語]]の意味によって異なります。 正確な規則は [CITE[The Unicode Standard]] の[[適用範囲外]]です。 [SRC[>>18]] [9] 一般的な既定の[[レンダリング]]は、 [[line break]] の前に[[ハイフン]]を挿入するものでありますが、 多くの場合にこれでは不十分か、誤りとなります。 [SRC[>>18]] [11] この [[Unicode]] の定義からは、 [[ハイフン]]以外の[[レンダリング]]も可能であるかのように捉えられます。 [[ラテン文字]]以外では[[ハイフン]]以外による[[ハイフネーション]]も行われますし、 [[ハイフン]]記号なしの語中の分断が起こる[[言語]]や[[用字系]]もあります。 そうしたものに [CODE(charname)@en[SHY]] を利用可能な実装があるのかは謎ですし、 [CODE(charname)@en[SHY]] を記述した文書があるのかも、 そのメリットも謎です。 [12] この[[文字]]は歴史の割に[[相互運用性]]が低そうで、 あまり使われていないのではないかとも思われますが、 目に見えないだけによくわかりません。 統計データなどは無いものでしょうか。 * 関連 [10] [[ハイフン付け]]可能な位置を表す[[文字]]である [CODE[U+2027]] [CODE(charname)@en[HYPHENATION POINT]] とはまったく異なります。 * 歴史 - [1] ''Soft hyphen (SHY) - a hard problem?'' - [2] [CODE(char)[SOFT HYPHEN]]。 - [3] [[欧文]]だと、[[ハイフネーション]]があるわけです。で、ハイフネーション可能位置に [CODE(char)[SHY]] を挿入しておいて、行末にそれが現れたときは、 [CODE(char)[[[HYPHEN]] の[[字形]] + [[改行]]になる、という寸法。 - [4] ところが、規格の解釈に2説あるらしいんです。詳しくは >>1 を見て欲しいのですが、行内にある時には表示しないのだというのと、表示する (というか、行末でハイフネーションにだけ使用する) という説みたいです。 [FIG(quote)[ [19] [[JIS X 0213:2000]] 6.5.2 m) 2) ラテン1互換文字 > [B[備考]] [SNIP[]] また, [[SOFT HYPHEN]] ([[SHY]]) は, [B[ISO/IEC]] [B[8859]] では, 単語内で改行が起こる際に, [[HYPHEN]] と同一か又は似た文字で表示される文字と 規定されるが, この規格では, 常に [[HYPHEN]] と同一か又は似た文字として表示してもよい。 ]FIG] [13] [CITE[n506.pdf]], [TIME[2000-10-09T21:03:13.000Z]], [TIME[2023-10-24T02:40:27.200Z]]