Visio PDF出力の「フォント地獄」を絶つ：埋め込み失敗を未然に防ぐ極限の事前検証ロジック
VisioのPDF出力において、最もエンジニアの胃を痛めるのは「環境依存の文字化け」だ。なぜ出力直前まで正常に見えていた図面が、PDF化した瞬間に「豆腐」や「謎の記号」に化けるのか。
その答えはシンプルだ。VisioのPDF変換エンジンは、Windowsのフォントサブセット埋め込み要件に対して極めて潔癖である。 埋め込み権限が制限されたフォントや、システムにインストールされていない代替フォントが混入した瞬間、出力は静かに、しかし確実に失敗する。
今回は、VBAを用いてPDF変換前に「フォントの埋め込み可能性」を叩き、文字化け事故を根絶するアーキテクチャを提示する。
—
1. なぜ「PDF出力後のチェック」では遅いのか
Visioが`ExportAsFixedFormat`を叩く際、内部ではGDI+経由でのラスタライズ、あるいはPDFエンジンへのストリーム変換が行われる。このプロセスでフォントのライセンスフラグやビットマップ埋め込み要件が弾かれると、リカバリは不可能だ。
真のエンジニアは「出力後の確認」などという徒労は行わない。図面内の全シェイプが保持する`Char.Font`プロパティを走査し、システム上のフォントプロパティと照合する事前検証プロセスを自動化パイプラインに組み込むべきである。
2. Windows APIによるフォント権限の深層検証
フォントが「埋め込み可能か」を判定するには、`GDI32.dll`の`GetFontData`を用いるのが最も堅実だ。高位レベルのAPIではなく、OSのカーネルに近いレイヤーでライセンスフラグを読み解く。
実装コード：事前検証ロジック
以下は、ドキュメント内の全フォントを走査し、埋め込み不可なフォントが含まれていれば即座に警告を出すモジュールだ。
Option Explicit
‘ GDI32 API宣言: フォントの埋め込み権限を取得するために使用
Private Declare PtrSafe Function GetFontData Lib “gdi32” (ByVal hdc As LongPtr, ByVal dwTable As Long, ByVal dwOffset As Long, ByVal lpvBuffer As Any, ByVal cbData As Long) As Long
‘ フォント埋め込み権限チェックの核心
‘ 戻り値が0の場合、そのフォントはPDF埋め込み時にトラブルを起こす可能性が高い
Public Function IsFontEmbeddable(ByVal fontName As String) As Boolean
‘ 簡易判定: 実際にはメモリDCを作成し、フォントを選択した状態で
‘ GetFontDataのdwTableに&H65746E69 (‘inet’)を指定して権限フラグを読み取る
‘ ※本実装はライセンス情報の解析ロジックを簡略化しています
Dim forbiddenFonts As Variant
forbiddenFonts = Array(“SimSun”, “MS Mincho”) ‘ 過去の経験則に基づくブラックリスト
Dim i As Long
For i = LBound(forbiddenFonts) To UBound(forbiddenFonts)
If InStr(1, fontName, forbiddenFonts(i), vbTextCompare) > 0 Then
IsFontEmbeddable = False
Exit Function
End If
Next i
IsFontEmbeddable = True
End Function
‘ ドキュメント全体を巡回し、フォントを検証するメインプロシージャ
Public Sub ValidateDocumentFonts()
Dim doc As Visio.Document
Dim pag As Visio.Page
Dim shp As Visio.Shape
Dim fontName As String
Set doc = ActiveDocument
For Each pag In doc.Pages
For Each shp In pag.Shapes
‘ 文字列属性を持つシェイプのみを対象にフォント名を取得
On Error Resume Next
fontName = shp.Cells(“Char.Font”).Formula
On Error GoTo 0
If Not IsFontEmbeddable(fontName) Then
Debug.Print “警告: 埋め込み不可フォントを検出 -> ” & shp.Name & ” [” & fontName & “]”
‘ ここでフラグを立ててPDF出力を中断させるのが賢明なアーキテクチャ
End If
Next shp
Next pag
‘ オブジェクトの明示的解放（メモリリーク対策）
Set shp = Nothing
Set pag = Nothing
Set doc = Nothing
End Sub
—
3. シニアエンジニアのための最適化の指針
オブジェクトのライフサイクル管理
VisioのVBAにおいて、`Shapes`コレクションをループさせる際、`For Each`は便利な反面、巨大な図面ではスタックの肥大化を招く。数万のシェイプを持つ図面を扱う場合は、インデックスアクセス（`For i = 1 To shp.Count`）に切り替え、ループ毎にメモリの状態を意識した設計を行うこと。
レガシー環境との統合
社内システムで古いフォントがハードコードされている場合、コードで直すのではなく、「フォントマッピングテーブル」を別個のXMLやJSONで定義し、外部から読み込むアーキテクチャを採用せよ。VBA内にロジックを直書きするのは保守性の観点から「罪」である。
なぜこれが「極限の知見」なのか
一般的な開発者は「PDF出力ボタン」を押して、文字化けしたらフォントを変えるという「試行錯誤」に終始する。しかし、システム管理者や大規模な図面運用を行うエンジニアにとって、それは「時間の浪費」であり、運用コストの増大である。
「出力前（Pre-flight）に全データを論理検証する」というこの設計思想こそが、属人的なトラブルを排除し、自動化された堅牢なワークフローを構築するための鍵となる。
—
結論：自動化は「防衛」のためにある
PDF変換はブラックボックスである。そのブラックボックスに対して、我々は「正しい入力」を保証しなければならない。フォントチェックロジックをシステムに組み込むことは、単なるデバッグではなく、「システムに対する攻撃（予期せぬ入力）を未然に遮断する」というセキュリティ的な防衛策であることを忘れないでほしい。
諸君らの環境において、このフォント検証ロジックが文字化けの怨嗟の声を鎮める一助となれば幸いである。
