ulCodePageRange not set in NotoSansSinhala-Regular.ttf

[plutext]

#304 fixed this issue for NotoSans; building Noto Sans I have confirmed the fix worked, see further https://github.com/googlei18n/noto-fonts/issues/1046#issuecomment-427291648

The build said it was using ufo2ft-2.3.1-py2.

However

ttx NotoSansSinhala-Regular.ttf

on freshly built ttf still yields:

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

The result is that when Word converts a docx using this font to PDF, some other font is substituted.

If I compare that to Nirmala (the Sinhala font Word uses on my computer), I see

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

Altering NotoSansSinhala-Regular.ttx to match, then ttx'ing it back to ttf, I confirmed Word 2016 does now use this font in its PDF output.

[anthrotype]

Thanks for the report.
I think we should change the ufo2ft calcCodePageRanges so that it always at least enables one bit (the first one, for "Basic Latin" "Latin 1") when no bits are enabled following our current algorithm:

https://github.com/googlei18n/ufo2ft/blob/c9925b38a103d2396528a5ec0b23d26016969e25/Lib/ufo2ft/util.py#L179-L265

Or even simpy enable Basic Latin all the time?

[anthrotype]

sorry, the bit 0 of OS/2.uCodePageRange1 is for codepage 1252, aka Latin 1.

[madig]

@moyogo