zplCloud Blog
SVG から TTF へ: ロゴやアイコンをグラフィックではなくプリンターフォントとして配布する
^A@N,50,50,E:MYICONS.TTF: 10 KB の ^GFA ブロックの代わりに、ラベルごとにグリフ参照が 1 つあるだけです。
グラフィックが 1 枚ごとのラベルにもたらすコスト
ほとんどのラベルにはロゴや一連のピクトグラムが入っています。一般的なやり方は、それぞれをラスター画像として書き出し、ZPL の ^GFA ブロックとして埋め込む方法です。これは動作しますが、3 つの意味で同時にコストがかかります。
データ量。 ^GFA は 1 ドット 1 ビットのモノクロビットマップで、16 進数として送信されます。計算は単純です。
bytes ≈ (width_dots × height_dots) / 8 × 2 (÷8 = bits→bytes, ×2 = hex encoding)
203 dpi で約 25 × 25 mm、つまり 200 × 200 ドットという控えめなロゴでも、ビットマップは 200 × 200 / 8 = 5 000 バイトになり、データストリーム上ではおよそ 10 000 文字の 16 進数になります。しかもラベル 1 枚ごとにです。同じ物理サイズを 300 dpi で表す場合は 295 × 295 ドット、約 21 800 文字になります。
品質。 ビットマップは、生成時の解像度に固定されています。それより大きく印刷したり、デザインを 300 dpi や 600 dpi のプリンターに移したりすると再サンプリングが起こり、ブランドを象徴する要素のエッジがぼやけます。
速度。 プリンターはラベルごとにグラフィックを受信し、デコードし、ラスタライズします。テキストであれば描画するだけです。
フォントは、プリンターがすでに描き方を知っているグリフのライブラリです
SVG → TTF エディターは、お手持ちの SVG アイコンから 1 つの TrueType フォントを作成します。各アイコンは私用領域のコードポイント (U+E000、U+E001 など) 上のグリフになります。これはまさにこの用途のために予約された Unicode の範囲です。
そのフォントは、デザイナーの Zebra Fonts タブからプリンターのフラッシュメモリへ一度だけ、たとえば E:MYICONS.TTF としてアップロードします。その後は、ラベル側でグリフを参照します。
^XA
^FO50,50^A@N,50,50,E:MYICONS.TTF^FD^FS
^XZ
パラメーターの順序に注意してください。^A@ は向き、高さ、幅、そしてフォントのパスの順に指定します。^A@N,E:MYICONS.TTF のように向きの直後にパスを書くのは正しい ZPL ではありません。プリンターは既定のフォントにフォールバックし、なぜアイコンが文字になるのかと午後いっぱい悩むことになります。
フォントが常駐した後は、同じラベル内の以降のフィールドについて ^A@N,50,50,E:MYICONS.TTF を ^A@N,50,50 と短く書けます。プリンターは最後の ^A@ のフォント選択を保持するためです。
前提を明示した数値
^GFA 画像 | TTF プリンターフォント | |
|---|---|---|
| 前提 | 200 × 200 ドットのアイコン、モノクロ、16 進エンコード | グリフ 3 個のフォント、約 3 KB |
| ラベル 1 枚あたり | 約 10 000 B | 約 125 B (グリフを 1 つ含むフィールド) |
| アップロード | ラベルごとに毎回 | 一度だけ、合計約 3 KB |
| ラベル 10 000 枚 | 約 100 MB | 約 1.25 MB + 3 KB |
| ラベル 100 000 枚 | 約 1 GB | 約 12.5 MB + 3 KB |
この要素については、送信バイト数が 80 分の 1 になります。115 200 ボーのシリアル接続や混雑した Weblink トンネルでは、この差がキューをさばけるか、それとも積み上がるかの差になります。
拡大縮小のコストはかかりません。同じグリフを ^A@N,20,20 としても ^A@N,120,120 としても、プリンターのフォントエンジンがベクター輪郭から描画するため、203 dpi でも 300 dpi でも 600 dpi でも鮮明です。
フラッシュメモリは有限です。アップロード前に確認してください
プリンターのメモリは潤沢ではありません。特に古いデスクトップ機ではそうです。GK420 は全体で数メガバイトしかありません。フォントを送り込む前に、そのサイズを把握してください。
- 数個のグリフからなるアイコンフォント: 1 桁台の KB です。問題になることはありません。
- Unicode 全体をカバーするテキストフォントは別物です。ZPLCloud の Unicode フォントは 11 MB、その軽量版でも 7 MB あります。これらは GK420 には収まらず、十分なフラッシュメモリを備えたプリンター向けです。
- フリート全体に展開する前に、
! U1 getvar "memory.flash_free"で空き容量を確認してください。
手順
1. SVG → TTF エディターに SVG を投入します。それぞれが PUA コードポイント上のグリフになり、エディターが割り当て (U+E000 以降) を表示します。
2. フォントをビルドし、選択したプリンターにアップロードします。1 回の操作でフリート全体に適用できます。
3. デザイナーでアイコンライブラリを開き、アイコンをキャンバスにドラッグします。正しいコードポイントとフォントパスにすでに紐付いたグリフ要素として配置されます。16 進コードを手入力する必要も、^GF ブロックを保守する必要もありません。
新しいアイコンやロゴの変更も同じ 3 ステップです。フォントを作り直し、配布すれば完了します。ラベルのデザイン自体は変わりません。デザインはコードポイントを参照しており、そのコードポイントが新しい図案を描くようになるだけです。
それでもグラフィックが正解である場合
フォントはモノクロの輪郭です。次の場合は ^GFA を使ってください。
- 写真、グラデーション、あるいは中間調を含むもの (サーマルプリンターはいずれにせよディザリングします)
- ラベルごとに変わる 1 回限りのグラフィック、たとえば出荷ごとの地図や署名画像
- ビットマップとして受け取り、きれいにベクター化できない図案
ロゴ、危険標識、輸送用ピクトグラム、繰り返し使う UI アイコン、つまり実際にラベルに載っているものの大部分については、フォントを使う方法の方が小さく、鮮明で、高速です。
きれいに変換できる SVG
変換ではパスがグリフの輪郭になります。時間を節約するルールが 2 つあります。
- SVG を書き出す前に線を輪郭化してください。グリフは塗りつぶされた図形であり、1 px の線にはフォントエンジンから見て太さがありません。
- テキストをパスに変換してください。 SVG 内のテキスト要素は、コンバーターが持っているはずのないフォントに依存しています。