I would like to request an export option for Japanese fonts.
After updating to Glyphs 3.5, I noticed that the export behavior for Japanese OTF fonts seems to have changed.
I compared an OTF exported from an older version of Glyphs with an OTF exported from Glyphs 3.5. In the Glyphs 3.5 export, I found an additional legacy Japanese cmap subtable:
cmap platformID 3 / platEncID 2: Windows Shift_JIS
This subtable was not present in the older export I compared it with.
For some Japanese OpenType fonts, especially fonts that need compatibility with older Windows applications or legacy Japanese environments, it would be useful to have an option to explicitly export a legacy Shift_JIS cmap subtable and appropriate CodePageRange settings.
Specifically, an option to export:
cmap platformID 3 / platEncID 2: Windows Shift_JIS
OS/2 ulCodePageRange settings for Japanese / Shift_JIS compatibility
would be very helpful.
At the moment, it is not very clear how Glyphs decides whether to include these legacy Japanese compatibility records. For Japanese fonts, being able to explicitly enable or disable this behavior would make the export process safer and easier to control.
Would it be possible to add a custom parameter or export setting for this?
For example:
Export Shift_JIS cmap
Export Japanese CodePageRange
or a combined parameter such as Export Legacy Japanese Compatibility Tables
I would like to add some context about why I requested this option.
After updating to Glyphs 3.5, some Japanese kana OTF fonts that had previously exported and worked without any problems started showing issues in Adobe applications.
The same kana font exported from an older version of Glyphs 3.4.1 works correctly in Adobe Illustrator and Photoshop. However, the OTF exported from Glyphs 3.5 sometimes shows kana characters as tofu in Illustrator, and in some cases the font does not display correctly or causes an error in Adobe applications.
The glyph outlines are present, and Font Book can display the kana, so this does not seem to be a simple missing-outline issue.
I am not saying that the additional Shift_JIS cmap is definitely the cause. I only noticed it as one difference between the older export and the Glyphs 3.5 export. The issue may be related to another table or export setting.
This is why I think it would be useful for Japanese font production to have explicit control over legacy Japanese compatibility records, such as the Shift_JIS cmap and Japanese CodePageRange settings.
I understand that the “Export ShiftJIS Cmap” custom parameter can be used.
In my opinion, a legacy Shift_JIS cmap is only needed in specific cases, such as compatibility with older Japanese Windows environments or legacy applications.
For most modern Japanese OTF fonts, it may be safer not to export it by default, unless the user explicitly enables it.
Would it be possible to consider making “Export ShiftJIS Cmap” disabled by default, and letting users enable it with the custom parameter when needed?