SVG を BMP に変換

この二つの形式はあらゆる点で対極にあります。SVG はテキストです。パスや塗り、変形の一覧をレンダラーが望みの大きさで絵に変えます。ですからファイルには解像度がなく、決まったバイト数もありません。BMP はすでに描き終えた絵そのもので、色を並べた行として圧縮も構造も解釈の余地もなく保存されています。

この落差がこのページの主題そのものです。一方向へ行くのはレンダリングです。サイズ・背景・アンチエイリアスについて、一度だけ、そして恒久的に決める作業です。逆方向は原理的に不可能で、バイト列の格子から、それを描いた形状に戻る道はありません。

SVG の width と height 属性は目安であって大きさそのものではありません。絵は viewBox によって定義され、任意の解像度で書き出せます。ですから変換はどこかで大きさを決める必要があり、scale の設定がその決定に当たります。既定では幅 1024 ピクセルでレンダリングされ、高さは絵の縦横比に従います。scale は 0.1 から 10 まで動き、幅にして 102 から 10,240 ピクセルになります。

行き先が実際に必要とする数値を選んでください。手に入る中でいちばん大きな値ではなく。ここでのコストは異例に急峻だからです。PNG や WebP と違い、ビットマップの大きさは絵の内容にまったく左右されません。幅を倍にすれば、絵が精密なイラストでも 1 本の黒い線でも、ファイルは 4 倍になります。

1 画素は青・緑・赤の順で 3 バイトを取り、各行は 4 の倍数に切り上げてパディングされます。54 バイトのヘッダーを足せば、それでファイル全体です。1,024 ピクセル四方なら 1 行あたり 3,072 バイト、画像データが 3,145,728 バイトで、合計 3,145,782 バイトになります。

ですから数百バイトの SVG が、既定の設定でおよそ 3 メガバイトになり、scale 2 ならおよそ 12 メガバイトになります。これは変換器の欠陥ではなく BMP という形式そのものの性質で、選べる立場にある人が別の形式を選ぶ理由でもあります。行き先にサイズ上限があるなら、変換したあとではなく、変換する前にこの掛け算をしておいてください。

ここで書かれるビットマップは 1 画素あたり 24 ビットで第 4 チャンネルを持ちません。アルファを定義するヘッダーの亜種は存在しますが、その対応状況は、まさに BMP が選ばれる理由を裏切るようなもので、だから透明はまず解決しておく必要があります。

絵は何もない状態にレンダリングされ、その後 1 回の処理で背景色に平坦化されます。この順番には意味があります。先に塗りつぶしてから拡大縮小すると、塗りが端ににじみ、透明な画像を先に拡大縮小してから平坦化すると、半透明の縁が残りそれを塗りが暗くしてしまいます。色は、ビットマップが実際に置かれる面に合わせて設定してください。白が既定値で、暗いパネルの上では誤りです。

レンダリングはブラウザー自身の SVG エンジンではなく、WebAssembly にコンパイルされた resvg が行います。これは意図的な選択です。SVG を canvas に渡すと、そのブラウザーの気分次第の結果になり、フォントの計測方法もフィルターの対応も異なり、同じファイルでも Chrome と Safari で見た目が違うことがあります。1 つのレンダラーを使えば、どの機械で作ってもビットマップは同一になります。

これはほとんどの変換先より重要な点です。機器やインストーラーに載るビットマップはたいてい一度だけ確認されてそのまま信頼され、参照とバイト単位で比較されることさえあります。ブラウザーによってレンダリングが変わってしまうと、その比較自体が意味を失います。

SVG は文字をテキストとして保存し、書体は名前で参照します。そのフォントがファイルに埋め込まれていなければ、レンダラーは別のものを選び、丁寧に字間を調整したロゴタイプが、違う字形と違う字間で戻ってきます。これがレンダリングされた SVG がおかしく見えるいちばんよくある原因です。

直す場所はここではなくデザインツールです。書き出す前に文字をアウトラインやパスに変換すれば、文字は誰にも置き換えられない形になります。それは自分の管理下にないシステムに絵を渡すときにも、とにかくやっておく価値があります。

読み込みにライブラリを必要としないからです。小さなディスプレイを駆動するマイコンは、54 バイトのヘッダーを飛ばしてループでバイトをフレームバッファーにコピーするだけで済みます。同じ機器で PNG に対応しようとすれば、展開器・メモリー確保・チャンク解析を、32 KB の RAM しかないかもしれないものに追加することになります。

同じ論理は、プラットフォーム自体のビットマップ呼び出しで読み込むインストーラーのリソースや、古い Windows のコントロール、コーデックを介さずに画像を比較するテストの固定資産にも当てはまります。いずれの場合も、選ばれているのは予測可能性であり、メガバイトはその代償です。

ビットマップを削除しても、また作れます。SVG を削除すると、あとに残るのはそのビットマップだけで、絵を有用にしていたすべて——編集のしやすさ、任意の解像度、バージョン管理で差分の追えるテキスト履歴——が永久に失われます。BMP をトレースしてパスに戻すのは、輪郭を推測する作業であり、ノードが多く曲線の質が劣る別のファイルを生みます。

変換は書き出しの工程として扱ってください。理想は手作業ではなくビルドが行う工程です。来年パネルに別のサイズが必要になったら、3 メガバイトのビットマップを拡大縮小するのではなく、ベクターから再レンダリングしてください。

セット丸ごとをドロップしてください。すべてのファイルが同じ scale で同じ背景に平坦化されます。行き先が背景色ばらばらのパネル画像より、そろっているほうを求めていることがほとんどだからです。

合計サイズには注意してください。20 枚の絵を既定の scale で処理すると、ZIP にする前でおよそ 60 メガバイトのビットマップになり、スマホでは動作が遅くなり、小型機器のストレージを埋め尽くすには十分な量です。ディスプレイが実際に表示できる大きさまで scale を下げることが、その数字を減らすいちばん効果的な手段です。