- Justifは、ブラウザのデフォルトレンダリングと出版物レベルのテキスト両端揃えを直接比較できるWebデモ
- ハイフネーションと文字の突き出し、幅の拡張、字間調整、最終行の間隔調整をそれぞれ設定可能
- 最小最終行幅と句読点のぶら下げ範囲を調整し、
text-wrap: pretty適用結果とも比較可能 - 英語の文学・技術文書だけでなく、ヘブライ語・アラビア語のRTLテキストと日本語をserif、sans、monospace書体で試せる
- 行数、ハイフンによる改行、はみ出した行、短い最終行、空白のばらつきとリバーなどをブラウザレンダリングと並べて測定する
両端揃えと詳細設定
- JustifはWeb上でKnuth-Plass両端揃えと複数のマイクロタイポグラフィ機能を試せるように構成されている
- ハイフネーション
- 文字の突き出し
- 幅の拡張
- 字間調整
- 最終行の間隔調整
- 句読点のぶら下げは文字の突き出しを有効にすると使用でき、行末と先頭行の開始位置、または全体範囲に適用可能
- 最小最終行幅は
0.33、本文幅は13emに調整できる
テキスト・書体比較と測定
- Alice in Wonderland、Frog Prince、Frankenstein、Ulysses、技術記事、RFC 2324、書体見本から比較するテキストを選択できる
- ヘブライ語・アラビア語のRTLテキストと日本語テキストも提供する
- 対応書体にはJunicode、EB Garamond、Alegreya、IM Fell English、Vollkorn、Amstelvar、Latin Modern、Georgia、Roboto Flex、Courier Prime、IBM Plex Mono、およびシステムフォントが含まれる
- 結果をクリックまたは長押しするとブラウザのデフォルトレンダリングが表示され、Justifのレンダリングと比較できる
- 比較ツールは
text-wrap: pretty、ぼかし処理、余白ルーラー、不均一な空白表示をサポートする - 測定項目には、行数、ハイフンによる改行、はみ出した行、短い最終行、リバーに加え、平均空白、自然な空白に対する平均偏差、標準偏差、最大空白が含まれる
1件のコメント
Lobste.rsの意見
このプロジェクトはFableでバイブコーディングしたとのこと https://news.ycombinator.com/item?id=48946738#49002419
LLM利用記を読むことには興味がないので除外したいが、実際にはコーディング支援を使った疑いがあるだけでも本文と無関係にタグが付くようだ
今回は利用した事実が明白だが、コーディング支援を使う貢献者を受け入れているという理由だけで、プロジェクト記事にタグが付いている例も見た
ただしバイブコーディングという用語とここで使われているタグはすでに有用性を失っており、LLM利用を扱う記事と、制作過程で偶然LLMを使った成果物とを区別する、より正確で生産的な表現が必要だ
ロブスター2: 「へえ……でもAlphaFoldとCRISPR、それに……ドゥグドゥグ……Fableを使ったらしい」
ロブスター1: 「なんてことだ、許せない！ 人類のために全部捨てて、黒板に色鉛筆でタンパク質を描き直すのに40年かけよう！」
成果物は非常に見事で、
microtypeパッケージを使っていないTeXよりもさらに良いこうした組版機能はブラウザが直接処理すべきだ
一部のブラウザは
text-wrap: prettyを実装しているが、数行程度に制限されているようだprettyがきちんと実装されているが、justifyと一緒に使うとバグがあるhttps://matklad.github.io/2026/02/14/justifying-text-wrap-pretty.html
text-wrap: pretty仕様を見ると、動作は定義されていない純粋なヒントにすぎないユーザーエージェントが速度より良いレイアウトを優先し、改行を決めるときに複数行を考慮すべきだという程度で、それ以外は
autoと同じだ極端に短い最終行、行間に川のように見える空白、連続するハイフンなどを避けられるが、具体的な改善方法はブラウザごとに異なる
複数のブラウザがそれぞれ違う実装をしたいと言ったため、過度な制約を避ける目的で仕様に入ったのだと記憶している
実装が結局SQLiteを使うことを露呈したためにWeb SQLが廃止されたのと似た事情だ
いずれはこれらの機能が
text-wrap: autoにデフォルトで適用され、text-wrap: prettyが何の効果も持たなくなることを願っているし、https://bugzilla.mozilla.org/show_bug.cgi?id=630181 も実装されることを期待しているこうしたヒントは新しいものではなく、
will-changeも前世代ブラウザ向けの最適化ヒントだった仕様化される頃にはFirefoxではほとんど不要で、一部の次世代エンジンではまったく役に立たないのにひどく乱用されたので、むしろ明白なハックだった
transformZ(0)を残しておく方がよかったかもしれないデモでは
text-wrap: prettyを切り替えながらブラウザごとの動作を試せるが、Blink・WebKit・Geckoの処理方式は驚くほど違うので、複数のブラウザで確認してみることを勧めるぶら下げ句読点は概して過剰に適用されていると以前から思っていた
目立つならもうやりすぎで、特に
“はほとんど常に目につくので、今の半分よりさらに控えめであるべきだむしろ段落冒頭の
“が小さな字下げのように機能している見た目は気に入っているぶら下げはオフにして、より微妙な突き出しだけを有効にした結果なら許容できるが、たいていは両方オフの方を好む
こうした処理はフォントに大きく左右される
私が使っているセリフ体フォントEquityでは、行末の“f,”にこれを適用すると、カーニングでコンマがすでにfの下に入り込んでいるため、fの上部まで行外に飛び出して不自然になる
セリフ体フォントが文字の尾や突起を文字幅の外に置いて自然に突き出させているなら、多くの句読点よりそちらの方が適切な対象かもしれない
字間調整では
letter-spacingが合字とうまくかみ合わないので危険だ合字が先に適用されると「T h i s i s fi n e!」のようになり、0でない
letter-spacingが合字を無効にすると、fがiの点と衝突するたいていは後者になるが、文字体系やフォント、明示的に有効化されたOpenType機能によって変わり、意図せず起こりやすい
合字のせいで字間調整が難しいという点には同意するが、デフォルトの制限である**±3%**なら見た目は悪くないと思う
「Type Specimen」の例の最初の段落末尾で、fl、fi、ffiの合字が連続する部分を確認でき、3%制限も設定可能だ
スウェーデン語では引用の始まりと終わりの両方に右ダブルクォートだけを使う
特定のテキストの言語やロケールをブラウザに伝えて、ダブルクォートや小数点などを自動処理させる方法があるのか、以前から気になっていた
例が改善効果を強調するために意図的に狭い行幅を使っている点は指摘しておきたい
一般には1行は小文字アルファベット2セット分、つまり約60文字幅が適切だと勧められている
差はずっと劇的ではなくなるが、それでもなお明確で、36emの行幅でもデフォルトより統計がかなり良い
別のサイトで作者がLLMを使ったと明かしたという理由で、バイブコーディングタグが付いたのではないかと疑っている
リンク先の内容はLLMやバイブコーディングと無関係なので、今やこのタグは魔女狩りのように感じられる
より明白な用途と衝突していて紛らわしく、やや攻撃的に見えることもある
一つのタグが二つの目的を持つのは理想的ではないが、おおむね刺激要素警告と、見たくない内容を自由に除外できる機能には賛成だ
紛らわしいタグではあるが、少なくとも作者に不利益を与えるものではない