Feature Request: Add option to export legacy Shift_JIS cmap and CodePageRange for Japanese font compatibility

Glyphs
1

I’m a Japanese font developer using Glyphs 3.

I’ve recently noticed that TrueType fonts exported from Glyphs 3 cannot be recognized correctly in some older Windows applications or embedded systems — for example, older versions of Adobe Illustrator, Microsoft Word, or printer controllers.

After inspecting the generated TTFs, I found two main differences between Glyphs 2 and Glyphs 3 that affect backward compatibility:

  1. Legacy cmap subtables are no longer generated.
  • Glyphs 3 exports only Unicode-based cmaps (platformID=0, platformID=3) — typically format 4 (Microsoft Unicode BMP).
  • However, older Japanese Windows applications rely on Shift_JIS / JIS encodings, which expect additional cmap subtables such as:
    • platformID=1, platEncID=0, format 2 or 4 (Mac / SJIS compatible)
    • platformID=3, platEncID=2 (Microsoft Shift_JIS)
  • Without these tables, the fonts are not recognized as Japanese fonts, and characters appear as tofu (□) or are replaced by fallback fonts.
  1. The OS/2 CodePageRange flag for Shift_JIS is no longer set.
  • In older versions (Glyphs 2), the exported TTF automatically set the OS/2.ulCodePageRange1 bits to indicate Shift_JIS support.
  • Specifically, the bit pattern 0x00020001 (which enables Latin + Shift_JIS) tells Windows that the font supports Japanese code pages.
  • This flag is required for older GDI-based applications to list and render the font correctly.

:light_bulb: Feature Proposal

I’d like to kindly request that Glyphs 3 include an export option (checkbox or custom parameter) such as:

“Include legacy Shift_JIS / JIS cmap and CodePageRange for Windows compatibility”

When enabled, it could:

  • Add cmap subtables for legacy encodings (platformID=1, platEncID=0, format 2 or 4).
  • Set the OS/2.ulCodePageRange1 bits to 0x00020001 (Latin + Shift_JIS).

This would restore compatibility with older non-Unicode environments, while keeping the modern Unicode cmaps for current platforms.

Currently, the only workaround is to use FontTools/TTX or other scripts after export to manually inject these cmap subtables and modify the OS/2 bit field, which is time-consuming and error-prone.

Adding this as a built-in export option would greatly help Japanese type designers who need their fonts to work on both new and legacy systems.

Thank you very much for considering this feature.

Best regards,

2

Additional Issue: Excel/Word font name tofu problem on Windows (GDI-based apps)

I’ve also discovered another compatibility issue that affects kana-only fonts exported from Glyphs 3, specifically when used in Microsoft Excel or Word on Windows.
In these applications, the font name’s English portion (e.g., “EB”) appears as tofu (□) in the font list.

Technical cause:
Excel still relies on the legacy GDI renderer, which expects the font to include:

  • a MacRoman (platformID=1, encodingID=0) or Symbol (platformID=3, encodingID=0) cmap subtable, and
  • Mac Roman name records (platform=1) in the name table (IDs 1, 2, 4, 6).

Currently, Glyphs 3 exports only the Unicode BMP cmap (platformID=3, encodingID=1) and no Mac Roman name records.
As a result, when Excel attempts to draw the English characters of the font name (e.g., “EB”), it cannot find the corresponding glyphs and displays tofu instead.

Workaround:
I’ve confirmed that this problem can be solved by post-processing the exported font with FontTools — adding simple ASCII-based MacRoman and Symbol cmap tables (format 4), and injecting Mac (platform=1) name records encoded in Mac Roman.
After doing this, Excel and Word display the font name correctly without tofu.

Feature Proposal:
I’d like to request that Glyphs 3 provide an optional export feature (or automatic fallback) that:

  1. Adds MacRoman (1,0) and Symbol (3,0) cmap subtables, populated from ASCII glyphs in the Unicode cmap.
  2. Adds Mac (platform=1) name records (IDs 1, 2, 4, 6) encoded in Mac Roman, derived from the English family/subfamily names.

Such a feature would allow kana-only or CJK fonts to display correctly in Excel, Word, and other GDI-based Windows applications, without requiring external FontTools processing after every export.

These two compatibility options — the previously mentioned Shift_JIS/JIS cmap + CodePageRange and this new MacRoman/Name fallback — would together make Glyphs 3 far more robust for Japanese font production, especially for those of us who still need to support older systems and office environments.

Thank you very much again for your attention and for continuously improving Glyphs.