フォント編集ソフト OTEdit問題

2025-09-20T00:00:00+00:00

フォント編集ソフト「OTEdit」で作成されたフォントの空グリフ問題について解説。Adobe-Japan1文字集合選択時に発生する空グリフによりフォールバック機能が正常に動作しない問題と、Pythonスクリプトを使った修正方法を紹介。

OTEditとは</h2>
OTEditとは、武蔵システム</a>が販売する OpenTypeフォントを作成・編集を行なうアプリケーションです。 Windows版とMac版が販売されています。
この手のアプリケーションとしては比較的安価で、使用しているフォント作家の方も多いようです。

OTEditの問題</h2>
(以下の考察は、OTEditの試用版による短時間の検証に基づいています。全ての機能を検証できている訳ではないので誤りを含む可能性があります。)
OTEditではAdobe-Japan1-3、Adobe-Japan1-4、 Adobe-Japan1-7の3種の文字集合のフォントを作成できます。新規作成時に選択した文字集合について全てのグリフを設定することを前提としているようです。 OTEditではフォントの新規作成時に選択した文字集合から文字の削除ができず、グリフが作成されなくとも「空グリフ」と各文字コードとグリフのcmapを作成してしまいます。
すべてのフォントがAdobe社の策定した日本語文字集合規格で作成されればよいのですが、実際にはいずれかの文字集合を選択してもすべてのグリフをサポートしないフォントも多いようです。例えば、IPAが配布するIPAフォントです。このフォントがどんなツールを使用して作成されたか不明ですが、 JIS X 0213:2012の文字集合をサポートしておりAdobe社の文字集合規格には従っていません。 Adobeの規格と並べると下表のような食い違いがあります。
文字セット</th> 総文字数</th> JIS第1～2水準（6,355字）</th> JIS第3～4水準（3,695字）</th> JIS規格外文字（異体字・独自文字）</th> 主な特徴</th></tr></thead>

JIS X 0213:2012</td> 11,233文字</td> 完全対応</td> 完全対応</td> 含まない</td> 公的規格・政府標準</td></tr>
Adobe-Japan1-3</td> 9,354文字</td> 完全対応</td> 非対応</td> 機種依存文字等含む</td> 一般用途標準</td></tr>
Adobe-Japan1-4</td> 15,444文字</td> 完全対応</td> 一部対応</td> 多数の独自文字・異体字含む</td> 商業印刷用</td></tr>
Adobe-Japan1-7</td> 23,060文字</td> 完全対応</td> 完全対応</td> 大量の独自文字・異体字含む</td> 最上位規格</td></tr> </tbody></table>
このようなケースでは、OTEditがcmapを生成しますが作者がグリフを用意していない文字には「空グリフ」をマッピングしてしまいます。
通常の使用ではあまり問題にならないかもしれませんが、フォント表示の際にフォールバックを前提にしているターミナルやブラウザなどで使用するとマズいことになります。本来であれば指定したフォントがグリフを持たない場合は、別のフォントのグリフが表示されます。しかしOTEditで作成したフォントでは、「空グリフ」が設定されている可能性が高いので「空白」が表示されてしまいます。
フォントの修正</h2>
最近購入した中村書体室の「カドマ-R」でこの不具合の遭遇したので、作者の方に相談させていただき手元のフォントに修正を掛けました。
対応は、空グリフと思われる文字を調査し該当文字についてcmapからエントリーを削除するという乱暴なものです。以下がそのスクリプトです。
分析スクリプト</h3>
#!/usr/bin/env python3 # -*- coding: utf-8 -*- # HomebrewのPython環境でFontToolsを使用 sys.path.insert(0, '/opt/homebrew/Cellar/fonttools/4.59.2/libexec/lib/python3.13/site-packages') try: from fontTools.ttLib import TTFont from fontTools.pens.recordingPen import RecordingPen except ImportError as e: print(f"Import error: {e}") sys.exit(1) def analyze_font_glyphs(font_path): """フォントファイルを分析して空のグリフとスペースグリフを区別する""" font = TTFont(font_path) cmap = font.getBestCmap() if 'CFF ' in font: cff = font['CFF '] charstrings = cff.cff[0].CharStrings else: print("This is not a CFF font") return hmtx = font['hmtx'] results = [] space_codes = [0x0020, 0x3000] # SPACE, IDEOGRAPHIC SPACE for unicode_code, glyph_name in sorted(cmap.items()): if glyph_name in hmtx.metrics: width, lsb = hmtx.metrics[glyph_name] else: width, lsb = 0, 0 if glyph_name in charstrings: charstring = charstrings[glyph_name] pen = RecordingPen() try: charstring.draw(pen) commands = pen.value has_drawing = len(commands) > 0 except Exception: has_drawing = False # グリフの分類 is_space_char = unicode_code in space_codes if not has_drawing: if width > 0: if is_space_char: glyph_type = "SPACE" else: glyph_type = "BLANK_WITH_WIDTH" else: glyph_type = "EMPTY" else: glyph_type = "NORMAL" results.append({ 'unicode': f"U+{unicode_code:04X}", 'code': unicode_code, 'char': chr(unicode_code), 'glyph_name': glyph_name, 'type': glyph_type, 'width': width, 'commands_count': len(commands) if has_drawing else 0, }) return results</code></pre> 判定基準は、次の通りです。 NORMAL: 描画データがあるグリフ</li> SPACE: スペース文字（U+0020, U+3000）で描画データなし</li> BLANK_WITH_WIDTH: スペース以外で幅はあるが描画データなし → 削除対象</li> EMPTY: 幅や描画データがない → 削除対象</li> </ul> 自動修正スクリプト</h3> def fix_font_cmap_only(input_path, output_path): """OTEで作成されたフォントのcmapテーブルから空グリフエントリを削除""" font = TTFont(input_path) original_cmap = font.getBestCmap() if 'CFF ' in font: cff = font['CFF '] charstrings = cff.cff[0].CharStrings else: return False hmtx = font['hmtx'] codes_to_remove = [] space_code = 0x0020 ideographic_space_code = 0x3000 for unicode_code, glyph_name in original_cmap.items(): if glyph_name in hmtx.metrics: width, lsb = hmtx.metrics[glyph_name] else: width, lsb = 0, 0 if glyph_name in charstrings: charstring = charstrings[glyph_name] pen = RecordingPen() try: charstring.draw(pen) commands = pen.value has_drawing = len(commands) > 0 except Exception: has_drawing = False # スペース文字以外で描画データがない場合は削除対象 if unicode_code not in [space_code, ideographic_space_code]: if not has_drawing and width > 0: codes_to_remove.append(unicode_code) # cmapテーブルから削除 for table in font['cmap'].tables: if hasattr(table, 'cmap'): for code in codes_to_remove: if code in table.cmap: del table.cmap[code] font.save(output_path) return True, len(codes_to_remove)</code></pre>修正結果</h2> 修正結果は次の通りです。 総cmapエントリ数: 10,161 → 5,762個（削減率: 43.3%）</li> 削除されたエントリ: 4,399個</li> Adobe Japan 1-4拡張範囲: 408個</li> その他の範囲: 3,991個</li> ファイルサイズ: 2.6% 削減</li> </ul> 修正の結果、今のところターミナルでも問題なく使用できています。 上記のスクリプトは精緻にテストを行なっていませんので、利用については自己責任でどうぞ。 AWSからSMSにメッセージを送る 2025-06-09T00:00:00+00:00 機密文書のメールでの共有</h2> 職場では取引先に資料を送付するのに暗号化したZIPでメールし、パスワードを電話で伝えるということをやっているようです。最低限のPPAP対策ですが、前時代的ですね。当然ですが、先方から「電話で伝えられても困る」とよくクレームを受けているようです。フィアル送信サービスも使っているようですが、「セキュリティ」と言う観点では何の解決にもなっていません。 メールで機密文書を送る方法について、現実的な選択肢を考えると以下のような評価かなと思います。 手段</th> 秘匿性（＝パスワードが第三者に見えないか）</th> 本人確認性（正しい相手か）</th> コメント</th></tr></thead> ① 暗号化ファイル、またはクラウドストレージ（認証なし） + パスワードを同じメールで送信</td> ❌：1通盗まれればすべて漏洩</td> ❌</td> PPAPの典型。秘匿性は完全に破綻</td></tr> ② 暗号化ファイル、またはクラウドストレージ（認証なし） + パスワードを別メールで送信</td> △：通信経路は一応分離だが同一インフラ内</td> ❌</td> 傍受・誤送信時に漏洩リスク高</td></tr> ③ 暗号化ファイル、またはクラウドストレージ（認証なし） + パスワードをSMSで送信</td> ◯：通信経路分離、実効性あり</td> ◯：端末本人であれば高い</td> 現実的な最低限の安全策</td></tr> ④ クラウドストレージ（認証あり）で共有</td> ◎：パスワード共有不要、URL単体では無効</td> ◎：ログインが必要なため本人限定</td> アクセス制限・ログ取得が可能</td></tr> ⑤ S/MIME暗号化メール</td> ◎：メール本文と添付がエンドツーエンドで暗号化</td> ◎：証明書により本人性確保</td> 導入済の組織間では最適解</td></tr> ⑥ GPG暗号メール / 公開鍵暗号によるファイル送信</td> ◎：パスワード共有不要</td> △：鍵配布と運用に依存</td> 高い秘匿性だが一般業務には難しい</td></tr> </tbody></table> パスワードを別メールで送信</h2> 本来はS/MIMEやGPGを検討すべきでしょうが、S/MIMEの費用捻出が難しく、GPGを使うリテラシーも無いので、次善の策としてSMSでパスワード送信は経路分離できている分マシだと思いました。 以下はメールとは別の手段でパスワードを伝えるだけならばPC上からこうやってSMSにメッセージを送ることもできますよというデモです。 GUIから任意の電話番号にSMSを送信できます。 Pythonの実行環境が必要です。 処理概要です。あくまでデモです。

AWSからSMSにメッセージを送る

Coded Chords - Python

ギターはHiFi化し、音楽はLoFi化している — Billboard Hot 100の音響分析で検証する

フォント編集ソフト OTEdit問題