Collabora CODE Dockerでカスタムフォントを利用できるようにする

Docker で実行されている Collabora Online CODE でカスタムフォントをレンダリングするには、フォントファイルをホスト上に保持し、同じディレクトリをコンテナのシステムフォントディレクトリとドキュメントシステムプレートの両方にマウントします。システムプレートは分離されたドキュメントプロセスにファイルを提供します。フォントを 1 つだけにマウントすると、/usr/share/fontsフォントメニューにフォントファミリーが表示されても、ドキュメントにレンダリングされない場合があります。このガイドでは、Docker Compose と現在の CODE イメージパスを使用しています/opt/cool/systemplate。別のイメージ行を使用する場合は、パスを確認してください。

管理しやすいフォントソースを選択してください

読み取り専用のバインドマウントは、通常、単一のDockerホストに対して最も簡単なオプションです。CODEコンテナの再作成やアップグレード時にフォントファイルが保持され、コンテナが読み取れるファイルを正確に確認できます。サーバーにインストールおよび再配布する権限のあるフォントファイルを使用してください。ライセンスを確認し、必要なファイルである場合を除き、デスクトップシステムのフォントディレクトリ全体をコピーしないでください。

ご使用の環境でサポートされている形式（一般的には TrueType ( .ttf) または OpenType ( .otf)）の非圧縮フォントファイルを使用してください。標準、太字、斜体、太字斜体など、ドキュメントに必要なスタイルを含めてください。ファミリー名とファイル名は明確にし、コンテナユーザーがすべてのディレクトリとファイルを読み取れるようにしてください。スタイルが 1 つしか含まれていないフォントを使用すると、ドキュメントで太字または斜体が要求されたときに Collabora が別のフォントに置き換える可能性があります。

まず、専用のホストディレクトリを作成し、承認済みのファイルをそこにコピーします。

sudo mkdir -p /srv/collabora/fonts
sudo cp BrandSans-Regular.ttf BrandSans-Bold.ttf /srv/collabora/fonts/
sudo chmod -R a+rX /srv/collabora/fonts

サンプルファイル名を実際のフォントファイル名に置き換えてください。現在のイメージではCODEプロセスが非特権アカウントで実行されるため、読み取り権限が重要になります。ディレクトリパスは変更しないでください。Composeのバインドマウントはこのパスを参照します。

ホストフォントツリーとシステムプレートの両方にフォントをマウントします。

既存のcollaboraサービスにdocker-compose.yml、以下のボリュームエントリを追加してください。既存のイメージ、ポート、ドメイン許可リスト、SSL設定、シークレット、再起動ポリシーはそのまま保持してください。以下のスニペットはフォントのマウントのみを示しています。

services:
  collabora:
    volumes:
      - /srv/collabora/fonts:/usr/share/fonts/truetype/more:ro
      - /srv/collabora/fonts:/opt/cool/systemplate/usr/share/fonts/truetype/more:ro

最初のターゲットは、コンテナの通常のフォント検出でフォントを利用できるようにします。2番目のターゲットは、分離されたドキュメント環境を準備するために使用されるテンプレート内にフォントを配置します。CollaboraのSDKマニュアルには、Docker用のこの2つの場所へのボリュームパターンが記載されています。/usr/share/fontsシステムプレートディレクトリ全体をマウントしないでください。イメージによって既に提供されているフォントが隠されてしまう可能性があります。

システムテンプレートのパスはバージョンに依存します。現在のCODE 26.04イメージのメタデータでは/opt/cool/systemplate、システムテンプレートのパスとして指定されており、Collaboraの最新ドキュメントでもその場所が使用されています。古いイメージやベンダー固有のビルドを使用する場合は、ターゲットパスを編集する前に、そのイメージのドキュメントまたは起動構成を確認してください。

コンテナを再作成し、フォントの検出を確認します。

Compose ファイルを保存し、フォント ファイルをホストに配置した後、CODE サービスを再作成して、Docker がバインド マウントを適用するようにします。

docker compose up -d --force-recreate collabora
docker compose exec -T collabora fc-list

出力結果から、フォントファミリー名またはマウントされたファイルパスを探してください。リストを絞り込むには、grepフォント自体が報告するファミリー名をパイプで渡します。例：

docker compose exec -T collabora fc-list | grep -i "Brand Sans"

コマンドが一致する結果を報告しない場合は、ホスト パス、ファイル権限、マウント インデント、およびコンテナ ログを確認してください。docker inspect実行中のコンテナで有効なマウントを検査するか、docker compose configYAML のインデントエラーを検出するためにを使用できます。docker compose downボリュームの変更を適用するためだけにを実行する必要は通常ありません。サービスを再作成するだけで十分です。

フォントが実際の文書内で正しく表示されることを確認してください。

通常の Nextcloud または WOPI 連携機能を使用してテスト文書を開き、短いテキストサンプルを選択して、フォントピッカーからカスタムファミリーを選択します。そのフォントで新しい行を入力し、保存して閉じ、再度ファイルを開きます。通常のテキストと太字のテキストを確認し、改行やページレイアウトを元の文書と比較します。メニューにファミリーが表示されるのは検出チェックに過ぎません。再度開いた後にテキストが表示されることが、実際のレンダリングチェックとなります。

• メニューにフォントは表示されるが、テキストが消えたり、フォールバックしたりする場合： 2番目のマウントがシステムプレートのフォントディレクトリを対象としており、同じファイルが含まれていることを確認してください。
• メニューにフォントが表示されません。ファイルが有効で読み取り可能であることを確認し、fc-list出力とコンテナの起動ログを調べてください。
• フォントはイメージが更新されるまで正常に動作します。両方のマウントがComposeに残っていること、およびホストディレクトリが一時コンテナパス内にないことを確認してください。
• 一部の文字のみ表示されます。選択したフォントにそれらのグリフが含まれていない可能性があります。必要な文字セットを含むフォントを追加するか、適切な代替フォントを使用してください。

バインドマウントを使用すると、フォントはCODEイメージから独立しますが、すべてのクライアントまたはすべてのドキュメントでレイアウトが同一になることは保証されません。フォントの置換、グリフの欠落、フォントバージョンの違い、およびドキュメント固有の書式設定によって、行の折り返しが変わる可能性があります。詳細な設定については、Collaboraのフォントインストールに関するドキュメント、CODE Dockerイメージガイド、およびCollabora Online SDKマニュアルを参照してください。CODEのバージョンを変更する場合は、マニュアルのDockerサンプルと最新のイメージに関するドキュメントを再度確認してください。