makeotf 2.7.8 and 2.7.9 produces probably incorrect Code Page Character Range value

[tamcy]

In this issue, when I say "old version" I refer to the following setup:

makeotf.py v2.5.2 Sep 20 2018
hotconv 1.0.109
makeotfexe 2.5.65596

And when I say "new version" I mean the followings:

makeotf.py v2.7.8 Aug 6 2019
hotconv 1.0.111
makeotfexe 2.5.65597

I have also tested building the font with makeotf.py v2.7.9 Sep 24 2019. The result is the same as 2.7.8.

I ran makeotf -v to get the makeotf.py version. Versions of hotconv and makeotfexe were taken from the built font.

---

I found this issue when trying to build my own modified version of Source Han Sans. I had been successfully used the "old version" to build my font, but not anymore after updating to the "new version" along with OS reinstallation. It looks like the problem is caused by the incorrect ulCodePageRange1 value in the OS/2 table when building the font with the new version of AFDKO.

Here's the OS/2 table built by the old version of AFDKO:

    <ulCodePageRange1 value="01100000 00111010 00000001 00000111"/>
    <ulCodePageRange2 value="00000000 00000000 00000000 00000000"/>

While the OS/2 table built by the new version of AFDKO looks like this:

    <ulCodePageRange1 value="01100000 00000000 00000001 00000111"/>
    <ulCodePageRange2 value="00000000 00000000 00000000 00000000"/>

As you see bit 17 (JIS/Japan), 19 (Korean Wansung), 20 (Chinese: Traditional) and 21 (Korean Johab) are all zeros.

I tried building the original, official version of Source Han Sans using this "new version", and it yields similar result:

(Left: official release; Right: built with new version of AFDKO. The JIS/Japan, Korean (Wansung & Johab) and Chinese: Traditional codepages are unchecked.)

The problem is that the font no longer works correctly in Windows (not sure about other OSes). For instance, when using it in MS Word,

• Word no longer groups this font with other Chinese fonts, but showing it next to other English fonts;
• Word falls back to other Chinese font when a CJK character/symbol is entered, probably because the font says it doesn't support it;
• force setting the font won't work - the kerning is wrong:
  

[josh-hadley]

@tamcy to aid us in debugging, can you please supply the commands you are using to build? Also any fontinfo or other files used for your modified build (that are changed from those in https://github.com/adobe-fonts/source-han-sans)?

[cjchapman]

@tamcy We were able to reproduce the problem, so there's no need for you to provide the info that @josh-hadley requested above. Thanks for reporting this issue.

[josh-hadley]

As @cjchapman mentions, we were able to reproduce the issue and have settled on a fix which should get merged soon. The underlying issue was actually in makeotfexe, not anything in the Python code, but makeotfexe gets called by makeotf.py so it can be hard to tell. Thanks again for reporting this!