Repository navigation
feat: Office 文書を画像へ描画する経路を base の外に置く（containers/docs の新設・案 A/B/C の比較） #219
Description
何を見つけたか
base に LibreOffice を入れないと決めたため、Office 文書を画像へ描画する経路が devbase のどこにも無いままになる。 #160 は base へ軽量の道具（poppler-utils / python3-pil / python3-defusedxml / python3-lxml / crosextra 2 種）だけを足し、LibreOffice（展開 372〜459 MB）は base に入れないと決めた。document-skills の視覚 QA は soffice --headless --convert-to pdf → pdftoppm の 2 段で、前段が欠けたままになる。
document-skills の thumbnail.py は office.soffice.run_soffice を import して LibreOffice を必ず呼ぶため、base だけでは動かない。clean.py と office/validate.py は soffice を参照しないので base で動く（#160 の実測）。
案の比較（#160 の本文から引き写す）
| 案 | 形 | base への負担 | 制約 |
|---|---|---|---|
| A | 派生イメージに置く（containers/docs を新設、または containers/latex を文書系として広げる） |
0。そのプロジェクトだけが払う | containers/latex が同じ形の先例（containers/latex/Dockerfile:7 が FROM devbase-base:latest） |
| B | 使い捨てコンテナで都度変換する | 0。初回だけ pull | base に docker-ce があるため成立する。イメージの選定と保守が要る |
| C | Google Slides へ変換して確認する | 0 | gws（@googleworkspace/cli）が base にある。Google アカウントとネットワークが要る |
#160 は A を推している。 containers/latex という先例があり、文書を作るプロジェクトだけが 372〜459 MB を払う形になる。devbase build <image> は $DEVBASE_ROOT/containers/<image> を汎用に建ててタグを devbase-<ディレクトリ名> にするため（lib/devbase/commands/container.py の _build_single_image）、containers/docs の新設に本体側の登録変更は要らない。
C はサイズ 0 で、しかも精度が高い。 配布する実物を見るため、書体の代替による字幅のずれが起きない。ただし Google アカウントが要るため、単独の解にはならない。実案件（volareinc/nyle-dx PR #5）ではこの手で 11 ページを確認した。
LibreOffice の実測（#160 の起票時、Ubuntu 26.04 / arm64）
| セット | 追加パッケージ | 展開 | ダウンロード | base（7.09GB）比 |
|---|---|---|---|---|
libreoffice-impress のみ |
78 | 372.1 MB | 101.8 MB | +5.2% |
libreoffice-impress + -writer + -calc |
90 | 458.6 MB | 122.7 MB | +6.5% |
libreoffice（メタ） |
98 | 475.0 MB | 126.4 MB | +6.7% |
libreoffice メタと impress+writer+calc の差は 16 MB しかない。 11 ページの日本語スライドを稼働中のコンテナで通した実測では、soffice --headless --convert-to pdf が 0.6 秒、pdftoppm で 11 枚の JPEG が出た。
決めること
- 案 A / B / C のどれを採るか。A を採るなら、
containers/docsを新設するかcontainers/latexを文書系として広げるか
どこで見つけたか
#160 の本文「Office 文書を画像にする経路をどうするか」。PLAN63（#161 / #160 の設計）で、conductor が範囲を「base への追加」に限ると決めた。
なぜこの変更の範囲外なのか
#160 の表題の範囲は base への軽量の道具の追加であり、派生イメージの新設はそれを超える。PLAN63 の受け入れ条件はすべて containers/base の中で閉じており、新しいイメージの追加は 1 つも含まない。
直さないと何が起きるか
スライドや文書を作っても、出来上がりを目視で確認できない状態が続く。文字のはみ出し・要素の重なり・表と枠の衝突は、描画しないと分からない。当面は案 C（Google Slides のサムネイル）で凌げるが、Google アカウントとネットワークが要るため、オフラインの作業では通らない。
由来
issue #160 / PLAN63（issues/old/PLAN63_base-image-rendering.md）
やらないと判断した（2026-09-29）
- 実害: Office 文書の出来上がりを devbase のコンテナの中だけでは目で確かめられない。当面は案 C（Google Slides のサムネイル）で確かめられ、実案件でも 11 ページをこの手で確認した。通らないのはオフラインの作業に限られる
- 費用の見積り: 案 A は派生イメージ 1 つの新設（Dockerfile・検査・文書）と、370〜459 MB のイメージの保守。案 B は変換用イメージの選定と保守
- 再び考える条件: オフラインの作業で Office 文書の描画の確認が必要になったとき、または
document-skillsの視覚 QA がsofficeの無い環境で止まる事象が devbase のコンテナで起きたとき
Activity