何を見つけたか
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 が出た。
どこで見つけたか
#160 の本文「Office 文書を画像にする経路をどうするか」。PLAN63（#161 / #160 の設計）で、conductor が範囲を「base への追加」に限ると決めた。
なぜこの変更の範囲外なのか
#160 の表題の範囲は base への軽量の道具の追加であり、派生イメージの新設はそれを超える。PLAN63 の受け入れ条件はすべて containers/base の中で閉じており、新しいイメージの追加は 1 つも含まない。
直さないと何が起きるか
スライドや文書を作っても、出来上がりを目視で確認できない状態が続く。文字のはみ出し・要素の重なり・表と枠の衝突は、描画しないと分からない。当面は案 C（Google Slides のサムネイル）で凌げるが、Google アカウントとネットワークが要るため、オフラインの作業では通らない。
由来
issue #160 / PLAN63（issues/PLAN63_base-image-rendering.md）
何を見つけたか
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 の本文から引き写す）
containers/docsを新設、またはcontainers/latexを文書系として広げる）containers/latexが同じ形の先例（containers/latex/Dockerfile:7がFROM devbase-base:latest）docker-ceがあるため成立する。イメージの選定と保守が要る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-dxPR #5）ではこの手で 11 ページを確認した。LibreOffice の実測（#160 の起票時、Ubuntu 26.04 / arm64）
libreoffice-impressのみlibreoffice-impress+-writer+-calclibreoffice（メタ）libreofficeメタとimpress+writer+calcの差は 16 MB しかない。 11 ページの日本語スライドを稼働中のコンテナで通した実測では、soffice --headless --convert-to pdfが 0.6 秒、pdftoppmで 11 枚の JPEG が出た。どこで見つけたか
#160 の本文「Office 文書を画像にする経路をどうするか」。PLAN63（#161 / #160 の設計）で、conductor が範囲を「base への追加」に限ると決めた。
なぜこの変更の範囲外なのか
#160 の表題の範囲は base への軽量の道具の追加であり、派生イメージの新設はそれを超える。PLAN63 の受け入れ条件はすべて
containers/baseの中で閉じており、新しいイメージの追加は 1 つも含まない。直さないと何が起きるか
スライドや文書を作っても、出来上がりを目視で確認できない状態が続く。文字のはみ出し・要素の重なり・表と枠の衝突は、描画しないと分からない。当面は案 C（Google Slides のサムネイル）で凌げるが、Google アカウントとネットワークが要るため、オフラインの作業では通らない。
由来
issue #160 / PLAN63（
issues/PLAN63_base-image-rendering.md）