WIP: BudouXとGoogle Sans Flexを導入し、日本語表示を改善 by ogwata · Pull Request #11 · vivliostyle/docs2.vivliostyle.org

ogwata · 2026-01-26T13:27:04Z

様々なデバイスに対応した改行位置の改良と欧文表示の改善を実装しました。

完了した変更

1. BudouX統合

VFM Loaderにカスタム関数を実装
日本語テキストにゼロ幅スペース（U+200B）を挿入
ビルド時処理のため、クライアント側のパフォーマンス影響なし

2. Google Sans Flex導入

バリアブルフォントで欧文表示を改善
Noto Sans JPと組み合わせて自動的にフォントを切り替え
1つのファイルで全ウェイトをカバー

3. CSS改行設定の最適化

見出し、段落、リスト、テーブルセルに word-break: keep-all と overflow-wrap: anywhere を追加
BudouXのゼロ幅スペースと組み合わせて自然な改行を実現

BudouX + CSS の組み合わせ効果

段落、見出し、リスト、テーブルにはBudouX（ゼロ幅スペース）とCSSの両方が作用しています。これは意図的な設計で、相乗効果を発揮します:

動作メカニズム

BudouX: 自然な文節位置にゼロ幅スペース（U+200B）を挿入
- 例: これは \u200B テストです \u200B 改行位置
CSS: 改行の優先順位を制御
- word-break: keep-all: 単語（文節）の途中で改行しない
- overflow-wrap: anywhere: 必要に応じてどこでも改行可能

相乗効果

自然な改行優先: BudouXが提供した文節位置で優先的に改行
極端に狭い場合の保険: コンテナが非常に狭い場合でも、最悪の場合は文字単位で改行してオーバーフローを防止
単語内改行の防止: keep-all により、BudouXが分割していない範囲では改行しない

実際の挙動

通常の幅（デスクトップ、タブレット）:

BudouXのゼロ幅スペース位置で自然に改行
文節が途中で切れることはない

狭い幅（モバイル）:

可能な限りBudouXの文節位置で改行
文節が長すぎる場合のみ、overflow-wrap: anywhere が発動

極端に狭い幅:

文字単位での改行を許可してレイアウト崩れを防止

この組み合わせにより、読みやすさとレイアウトの堅牢性を両立しています。

テスト結果

✅ 開発ビルド: 正常動作
✅ 本番ビルド: 57ページ生成、エラーなし
✅ PDF生成: 正常動作
✅ 日本語改行: 「そ」だけの改行が解消され、自然な位置で改行

影響

ビルド時間増加: 約2-3秒（許容範囲内）
依存関係追加: budoux (~50KB)
フォント: Google Sans Flex (CDN経由)

変更ファイル

src/loaders/vfm-loader.ts: BudouX統合
public/styles/global.css: フォントとCSS設定
package.json: 依存関係
_investigation/budoux-google-sans-flex-plan.md: 開発計画

Pull request overview

This pull request integrates BudouX for improved Japanese line breaking and adds Google Sans Flex as a variable font for better Latin typography. The implementation processes Japanese content at build time to insert zero-width spaces (U+200B) at natural phrase boundaries, allowing for better line wrapping on various devices.

Changes:

Added BudouX integration in the VFM loader to process Japanese HTML content at build time
Integrated Google Sans Flex variable font via CDN with updated font stack ordering
Added CSS line-breaking properties (word-break: keep-all and overflow-wrap: anywhere) to heading elements

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
src/loaders/vfm-loader.ts	Implements custom BudouX integration with regex-based HTML text node processing
public/styles/global.css	Adds Google Sans Flex font import, updates font stack, and adds line-breaking CSS to headings
package.json	Adds budoux ^0.7.0 dependency
package-lock.json	Locks budoux and its transitive dependencies (commander, linkedom, etc.)
_investigation/budoux-google-sans-flex-plan.md	Documents the implementation plan (contains discrepancies with actual implementation)
.gitignore	Adds .claude/ directory to ignore list

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

- Add error handling for BudouX processing - Extend word-break CSS to paragraphs, lists, and table cells - Improve body tag extraction regex (non-greedy, case-insensitive) - Add documentation about regex-based approach limitations - Note potential future improvement with DOM parser (linkedom) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

- Replace translateHTMLString() with custom applyBudouXToHTML() function - Document regex-based approach instead of built-in HTML method - Update code block handling risk section with actual implementation status - Add error handling documentation - Note future improvement suggestion (linkedom) This addresses Copilot review comments about discrepancies between plan and implementation.

MurakamiShinyu

BudouXを利用するのは反対です。Vivliostyle公式ドキュメントサイトは、それ自体がVivliostyle利用の参考になる例となるような、標準的なものとするべきであって、CSSの機能を使わない特殊な手法での拡張を使うべきではありません（文節での改行を実現するCSSの機能は word-break: auto-phrase です）。

また、ドキュメントサイトとして、これを利用するメリットよりもデメリットが多いと感じます。気がついた問題点です：

文節区切りのみで改行する方式では、1行の長さよりもだいぶ短いところで改行がされるので、そこで文が終わったように見えるなど多くの場合に読みにくい結果になります。たとえば「出版向け拡張Markdown記法」という長めの文字列内に改行できる箇所がありません（Chromeのword-break: auto-phrase では「拡張」のあとで改行可能ですがBodouXではまったく改行不可です）。
テキストをコピーしたときに、ゼロ幅スペースもコピーされます。これはテキストの再利用性を妨げます。

MurakamiShinyu · 2026-01-29T13:24:53Z

このPRでの変更箇所でないですが、丸付き数字（❶-❿）を @font-face で font-family: 'Circled Numbers'; としているのはどうしてですか？

docs2.vivliostyle.org/public/styles/global.css

Lines 15 to 28 in 0d363e0

    
           /* Noto Sans JP: 丸付き数字（❶-❿）を確実にカバー */ 
        
           @import url('https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@400;500;700&display=swap'); 
        
           /* 丸付き数字専用のフォント指定 (U+2776-U+277F) */ 
        
           @font-face { 
        
             font-family: 'Circled Numbers'; 
        
             src: local('Noto Sans JP'), 
        
                  local('Hiragino Sans'), 
        
                  local('Hiragino Kaku Gothic ProN'), 
        
                  local('Yu Gothic'); 
        
             unicode-range: U+2776-277F; 
        
             font-weight: 400; 
        
             font-style: normal; 
        
           }

docs2.vivliostyle.org/public/styles/global.css

Lines 53 to 55 in 0d363e0

    
           /* タイポグラフィ */ 
        
           /* Google Sans Flex を先頭に配置（欧文用）、次に Noto Sans JP（日本語用）、丸付き数字専用フォント */ 
        
           --font-sans: "Google Sans Flex", "Noto Sans JP", "Circled Numbers", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;

Noto Sans JPに❶-❿が含まれるなら、Webフォントとしてどの環境でもNoto Sans JPが有効になって、--font-sans で "Circled Numbers" より先にある "Noto Sans JP" が使われますね。なんらかの問題があってWebフォントのダウンロードができなかったとき、あるいはそれに時間がかかっている間だけ、@font-face で定義された "Circled Numbers" が使われて、その内容はOSに標準で入っているフォントが src: local(…) で指定されています。❶-❿だけをこのように特別扱いする必要があるほどドキュメントで使われているかというと、日本語版のVivliostyle Viewerのドキュメントの「設定パネル」のところでだけしか使われていません。

この "Circled Numbers" がないと何か問題があったのでしょうか？

@font-face

Google Sans Flexが丸付き数字（❶-❿）をカバーしているため、専用の@font-face定義は不要になった。 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

ogwata · 2026-01-29T14:44:05Z

'Circled Numbers' の @font-face 定義は、もともと丸付き数字（❶-❿）が欧文フォントにフォールバックされて、グリフが小さく表示されて見づらかった問題への対処として追加したものでした。

しかし、Noto Sans JP / Google Sans Flex をWebフォントとして導入したことで、丸付き数字は適切にレンダリングされるようになりました。テスト環境でも Google Sans Flex - 700 で表示されることを確認しており、ご指摘の通り 'Circled Numbers' の定義は不要になっています。

f4e70eaにて当該定義を削除しました。

ogwata · 2026-01-29T14:49:26Z

文節区切りのみで改行する方式では、1行の長さよりもだいぶ短いところで改行がされるので、そこで文が終わったように見えるなど多くの場合に読みにくい結果になります。たとえば「出版向け拡張Markdown記法」という長めの文字列内に改行できる箇所がありません（Chromeのword-break: auto-phrase では「拡張」のあとで改行可能ですがBodouXではまったく改行不可です）。

テキストをコピーしたときに、ゼロ幅スペースもコピーされます。これはテキストの再利用性を妨げます。

なるほど、そうかもしれません。少し考えてみるので時間をください。

ogwata · 2026-01-29T17:25:40Z

テキストをコピーしたときに、ゼロ幅スペースもコピーされます。これはテキストの再利用性を妨げます。

質問です。ゼロ幅スペースの混入によって、具体的にどのようなデメリットが考えられるでしょう？

MurakamiShinyu · 2026-01-30T01:23:27Z

テキストをコピーしたときに、ゼロ幅スペースもコピーされます。これはテキストの再利用性を妨げます。

質問です。ゼロ幅スペースの混入によって、具体的にどのようなデメリットが考えられるでしょう？

例えば、ドキュメントからコピーしたテキストをテキストエディタに貼り付けて利用するとします。そしてテキストの検索をするとします。たとえば「テキストの再利用性」で検索したとき、もしそのテキストの途中（テキストの/再利用性）にゼロ幅スペースが入っていたとしたら検索で見つからないということになります。ゼロ幅スペースは目に見えないので、利用者は何が起きているか分からず混乱します。

ogwata · 2026-02-02T05:12:52Z

@MurakamiShinyu

いろいろ考えてみましたが、ご指摘のように非標準であるBudouXの採用はやめて、word-break: auto-phrase、それからtext-wrap: balanceを組み合わせて実装しようと思いますが、どうでしょう？

ogwata and others added 2 commits January 26, 2026 22:25

chore: add .claude/ to .gitignore

1b644b3

ogwata requested review from MurakamiShinyu and Copilot January 26, 2026 13:29

Copilot started reviewing on behalf of ogwata January 26, 2026 13:29 View session

Copilot AI reviewed Jan 26, 2026

View reviewed changes

ogwata and others added 2 commits January 26, 2026 22:41

MurakamiShinyu reviewed Jan 29, 2026

View reviewed changes

refactor: remove unused 'Circled Numbers' @font-face definition

f4e70ea

Google Sans Flexが丸付き数字（❶-❿）をカバーしているため、専用の@font-face定義は不要になった。 Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

ogwata closed this Jan 29, 2026

ogwata reopened this Jan 29, 2026

ogwata marked this pull request as draft February 2, 2026 07:25

ogwata changed the title ~~feat: BudouXとGoogle Sans Flexを導入し、日本語表示を改善~~ WIP: BudouXとGoogle Sans Flexを導入し、日本語表示を改善 Feb 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WIP: BudouXとGoogle Sans Flexを導入し、日本語表示を改善#11

WIP: BudouXとGoogle Sans Flexを導入し、日本語表示を改善#11
ogwata wants to merge 5 commits intomainfrom
feat/budoux-google-sans-flex

ogwata commented Jan 26, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MurakamiShinyu left a comment

Uh oh!

MurakamiShinyu commented Jan 29, 2026

Uh oh!

ogwata commented Jan 29, 2026

Uh oh!

ogwata commented Jan 29, 2026 •

edited

Loading

Uh oh!

ogwata commented Jan 29, 2026 •

edited

Loading

Uh oh!

MurakamiShinyu commented Jan 30, 2026 •

edited

Loading

Uh oh!

ogwata commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

ogwata commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

完了した変更

1. BudouX統合

2. Google Sans Flex導入

3. CSS改行設定の最適化

BudouX + CSS の組み合わせ効果

動作メカニズム

相乗効果

実際の挙動

テスト結果

影響

変更ファイル

関連リンク

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MurakamiShinyu left a comment

Choose a reason for hiding this comment

Uh oh!

MurakamiShinyu commented Jan 29, 2026

Uh oh!

ogwata commented Jan 29, 2026

Uh oh!

ogwata commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ogwata commented Jan 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MurakamiShinyu commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ogwata commented Feb 2, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ogwata commented Jan 26, 2026 •

edited

Loading

ogwata commented Jan 29, 2026 •

edited

Loading

ogwata commented Jan 29, 2026 •

edited

Loading

MurakamiShinyu commented Jan 30, 2026 •

edited

Loading