LGC alpha: unset ulCodePageRange causes issues in some Windows apps

[codeman38]

On my Windows 7 machine, the current alpha builds of the Noto LGC fonts (including Mono) are unusable in certain applications such as Word and Sublime Text, because the ulCodePageRange field has all bits unset.

More specifically, the fonts are selectable in the font menu, but whichever Windows API these applications use considers them unsuitable for any character set, so anything set in these fonts is rendered with a fallback font of Arial.

Edited to add: I've confirmed that this issue is indeed due to ulCodePageRange by decompiling the fonts with ttx, replacing the value with that from the stable Noto LGC fonts, and recompiling. The fonts work as expected in Word and Sublime after that change.

[marekjez86]

@codeman38 : could you give me a link to a sample download which exhibits this issue? I downloaded https://github.com/googlei18n/noto-fonts/blob/master/alpha/from-pipeline/unhinted/ttf/sans/NotoSans-Regular.ttf , ran it through ttx and saw the following in the ttx output:

    <ulUnicodeRange1 value="11100000 00000000 00000010 11111111"/>
    <ulUnicodeRange2 value="01000000 00000000 00000000 00011111"/>
    <ulUnicodeRange3 value="00001000 00000000 00000000 00101001"/>
    <ulUnicodeRange4 value="00000000 00010000 00000000 00000000"/>
    <achVendID value="GOOG"/>

The above appears to be the correct behaviour.

[codeman38]

ulUnicodeRange does indeed look correct - the issue is with ulCodePageRange.

From https://github.com/googlei18n/noto-fonts/blob/7a6494d7/alpha/from-pipeline/unhinted/ttf/sans/NotoSans-Regular.ttf, decompiled via ttx:

    <ulCodePageRange1 value="00000000 00000000 00000000 00000000"/>
    <ulCodePageRange2 value="00000000 00000000 00000000 00000000"/>

For comparison, the same lines from https://github.com/googlei18n/noto-fonts/blob/7a6494d7/hinted/NotoSans-Regular.ttf:

    <ulCodePageRange1 value="00100000 00000000 00000001 10011111"/>
    <ulCodePageRange2 value="11011111 11010111 00000000 00000000"/>

[marekjez86]

@codeman38 : thank you for noticing this.
I created googlefonts/fontmake#304 to get the tools compiling the fonts changed to do "the right thing". I'll close this bug when the fontmake bug is resolved, unless it's OK with you to close this one and just track the fontmake bug.

[codeman38]

Based on the comments in #327, it seems that the best solution may be to set the code page ranges manually in the Glyphs (codePageRanges) or UFO (openTypeOS2CodePageRanges) source files - if it's set there, the value should carry over into the generated files.

This is starting to seem more urgent now that the phase3 fonts have been released and more people are trying to install them on Windows.

[anthrotype]

Yes. I consider this to be a source issue. The feature request to compute those ranges automatically is still pending, and I may get to there eventually. But as I said already, there is no consensus on how to "objectively" set those fields and the spec leaves it to the judgement of the designer to deem a given codepage range as "functional". So it's the responsibility of the font developer to specify those in the source file. The fact that the fonts exported from Glyphs.app do have some (even though not necessarily the correct) codepage bits set, it's because the embedded makeotf is doing that as fallback.

[sven-oly]

This has come up with the Osage Nation re: Noto Sans Osage. Is there something we can do to address this for specifc Noto Sans fonts?

[moyogo]

The code page ranges were fixed in Noto Sans 2.001 (4b9da60ee), Noto Sans Mono 2.002 (4b9da60ee), Noto Serif 2.001 (449470a4d) when the fonts were build with fontmake after googlefonts/fontmake#304 was merged.

This has come up with the Osage Nation re: Noto Sans Osage. Is there something we can do to address this for specifc Noto Sans fonts?

Let's open a separte issue for that.

[moyogo]

This has come up with the Osage Nation re: Noto Sans Osage. Is there something we can do to address this for specifc Noto Sans fonts?

Let's open a separte issue for that.

Actually the code page ranges of NotoSansOsage were updated in version 2.000 (72c0ac136).
I'm not able to reproduce the issue in Notepad and SublimeText, while I can with Noto Sans where ulCodePageRanges are not set.
Please open an issue if this is still not working.