[1] "word-wrap"のサンプル http://useyan.x0.com/s/html/css_sample/word-wrap.htm (名無しさん)

[2] Re: firefoxのurlライン・ブレーク問題 - WebStudio http://www.d-toybox.com/studio/weblog/show.php?mode=single&id=2006081701

[3] Firefox 3.1 for developers - MDC (2009-02-08 18:25:06 +09:00 版) https://developer.mozilla.org/ja/Firefox_3.1_for_developers#.E6.96.B0.E3.81.97.E3.81.8F.E3.82.B5.E3.83.9D.E3.83.BC.E3.83.88.E3.81.95.E3.82.8C.E3.81.9F.E3.83.97.E3.83.AD.E3.83.91.E3.83.86.E3.82.A3

[6] 見出しの改行位置を適正化する試み | tech - 氾濫原 ( (2017-02-15 17:42:09 +09:00)) https://lowreal.net/2017/02/14/2

[7] URLという難問 ~連載「組版夜話」第18話~ | クリエイターズステーション, 2021-04-23T08:33:53.000Z http://www.creators-station.jp/report/124811

[8] Android Developers Blog: Android 13 Developer Preview 2, 2022-03-20T21:37:01.000Z, 2022-03-21T03:25:02.439Z https://android-developers.googleblog.com/2022/03/second-preview-android-13.html

[25] 2022-10-24T11:51:36.900Z https://harp.lib.hiroshima-u.ac.jp/h-bunkyo/file/6627/20140519120915/bunkyokyoiku%28takagaki%29.pdf

[9] >>25 日本点字と漢点字の混在で分かち書き。

語中では改行しない。 justify もしないので行長に満たないとき行末が空く。

[10] 日本語文字の間ではどこでも改行できるって定説みたいになっていますけど、実はそれは正確ではなくて、静的に行を並べて段や頁を構成する媒体ではそうだという限られた条件の話でした。行が単独で表示される場面、例えば動画の字幕で文が途中で区切られつつ時間ごとに表示されるような媒体においては、単語の途中では改行できないし、単語の後で附属語の前で改行するのも禁止しないといけません。文中の改行を禁止するのが最も単純な実現方法ですが、文中で改行がすべて禁止されるわけではなく、文意上区切ってしまって構わない箇所というのは存在します。そしてそれは完全に個別の文に依存するのではなくて、文の構造によって決まる一般化可能な性質です。ということを、今次の万博の某国の展示動画 (日英文併記で、日本語の方は付属語の前で改行している) を見ながら知ったのでした。 2025-05-28T05:12:21.435Z

[11] 英語の方も単語区切りのどこでも切っていいとはいえず、何らかの法則性がありそうですよね。でも全く固定的でもなさそうですよね。たとえば in などの前置詞は続く言葉と同じ行にあったほうがいいのだろうけれども、 in ... で行を終わらせて引きを作ったほうが良さそうなこともありそうで、なんにせよ前の行が文の末端ではないことがわかる合図がないと誤読しそう 2025-05-28T05:14:54.853Z

[12] といったあたりはテレビや映画の字幕のような業界でノウハウが蓄積されていそう 2025-05-28T05:15:13.887Z

[13] 日本語なら、以下のような構造単位を考慮

• 動詞+助動詞(食べ/る は不可)
• 名詞+助詞(東京/へ は避ける)
• 連体修飾+被修飾(美しい/花 はOK、でも場合による)

• 助詞の直前で改行しない(例:
  • ×「行き/ます」→誤読や違和感
  • ○「行きます」か「行き/ましょう」など構文単位で切る)
• 複合語の途中で切らない(例:
  • ×「自動/車」→処理が不自然
  • ○「自動車」)
• 係り受けの構造を断ち切らない

[14] 英語なら、

• 前置詞句、名詞句、節の切れ目で処理
• 助動詞+動詞(will go)などの連結は極力分断しない

• 前置詞・冠詞・接続詞(in, on, a, and, etc.)を文頭に残さないのが望ましい
  • × This is a / pen.
  • ○ This is / a pen.
• 句・節のまとまりを分断しない
  • × He went / to the store.
  • ○ He / went to the store.

• [15] 静的でも文字が少ない媒体 (ポスター、標識など) では構造を表す改行が重要
• [16] UIはこれと同様の制約を持つが、組版ルールを流用してしまいがち
• [17] 特に日本語・英語ともに、構造意識のない改行は文意を損ね、UX上の障害となる

[18] CSS などの分野は機械的な実装の難度の問題とワープロの技術的蓄積があったことや、 組版系の専門家の声が大きく反映されやすかった(←実装されたとはいっていない) という歴史的、政治的な経緯で書籍組版系の考え方、 >>10 のいう定説に偏りがある

[19] 実際の Web は文書もアプリケーションもどっちもあるのでどちらの要件も見ていかないといけない。 ところが組版系の専門家は組版の伝統にしか興味がないので、アプリケーションのUIがどうあるべきかを何も提言してくれない。 UIの専門家はUIの重要性を説いて人気を得たり商売につなげたりすることにしか興味がないので、 今日できる方法 = アプリケーション開発者が個別に手をいれる方法ばかり着目して、 UI用レンダリングエンジンのあるべき言語と文字の挙動のモデル化をやってはくれない。 技術論よりも改善の実装技法(トリック)の共有に傾倒。

[20] 国際化の専門家を自称する人々は文字とフォントとせいぜい組版にしか興味がないのでこういう分野には首を突っ込んでこない。

[21] 自然言語の専門家は何か研究している可能性はあるが、実用に興味がないのかあまりこうした分野への入力になる業績が出てこない。

[22] これは既存の専門領域のどれにも完全には属しておらず、 「言語構造 × レンダリング × UI × 可読性 × 自動処理」 という複合的問題です。

このような分野では:

• フォントや禁則処理だけでなく、
• 接尾語や補助動詞の折返し挙動
• 語彙の視認性と意味的まとまりの扱い
• 多言語対応での語順変化と視線誘導の整合性

といった設計が必要になります。

[23] 現時点では、これを専門的に扱う層はほぼ存在しません。 一部の試み(例:読みやすい文体設計支援、短文における語順最適化など)はありますが、実装に落ちる形では滅多に見かけません。

したがって今必要なのは:

• 横断的知識をもつ実践者の育成
  • UIエンジニアかつNLPを理解し、CSS標準にも関与できるような人材
• 問題提起としての文献やフレームワーク
  • 「UIにおける意味構造保全のモデル」
  • 「助詞と視認性に関する改行禁則設計」
• 実装へのフィードバックループの創出
• 表記モデルと言語構造モデルを同一空間で語れる仕様提案者

[24] 「東京都」の「東」「京都」で改行は入れたくないなあ 2026-03-06T05:49:21.637Z

[26] DTPオペレーターや編集職、あといくらかは広告デザイナーなどもこういうノウハウは持っていそうだけれども、しかしまとまった形で世に出にくいよなあ 2026-03-06T05:51:35.671Z