Effect of no codepage claimed?

Hey all, but especially Win, Mac and Adobe gurus:

How do operating systems and apps respond differently to an OTF or TTF font which declares Unicode ranges but no codepages at all are supported?

If you have minimal glyph set or weird glyph set, is it better for the font to not claim any codepages supported? Or to claim codepage 2525 (WinANSI) ?

Comments

  • John Hudson
    John Hudson Posts: 3,204
    edited February 2017
    I'm not sure what the current state of play it, but it certainly used to be a bad idea for Windows not to claim OS/2 support for at least one 8-bit codepage, even if not actually fully supported in the character coverage. I recall such fonts not being usable in RichEdit environments, and fallback occurring. So I got into the habit of always claiming at least one 8-bit codepage, and more often actually including support for one, even if not actually needed for the primary script coverage of the font.

    Since I've not heard otherwise, I believe it is also still a procurement requirement from Microsoft for any fonts they license or purchase to have coverage for at least one Windows 8-bit codepage, usually CP1252 (not, as you typed, 2525).
  • Yes, there are still a few components that look for the cp1252 bit set and won't load the font without it. (sigh)
  • Thanks, guys. I knew this was an issue "back in the day," and I was about to file a FontLab VI bug on it... then I realized that any specific info I had on this in my head was going on 20 years old now.

    2525? Not sure how I made that typo on my number pad. Weird.
  • Ray Larabie
    Ray Larabie Posts: 1,432
    @Thomas Phinney
    Are you sure you didn't have Zager and Evans playing in the background?
  • I don't think the code page and unicode range bit fields in the OS/2 table matter as much for Windows as they do for Office.
  • Fair enough. I guess I should have said "Microsoft" rather than "Windows"