Postscript-flavored OpenType font not working in Windows. It's killing me, please help!

Oliver Weiss (Walden Font Co.)

I have no end of trouble getting my Postscript-flavored OpenType fonts to work reliably on Windows. I find most of them work ok in Notepad and Inkscape, but will not show any characters in the charmap app, and will not work at all in Wordpad. This doesn't happen with TrueType-flavored OpenType fonts. But I prefer the CFF fonts on Mac, and I'd rather only have one format. 

Could anyone please take a look at the attached test font and perhaps enlighten me? 

Incidentally, the font contains only a few characters that form a seamless border by typing
789
456
123


Thanks! 

Oliver

Mike Wenzloff

Windows wouldn't display your test font in the application I had open. So I quickly add to another font and used a stylistic set to swap the characters and activated that font.

You didn't have the /5 defined, so I copied a block and put it there.

Oliver Weiss (Walden Font Co.)

Thanks, Mike, that matches the results I've been getting. It just won't work in certain applications. 

Mike Wenzloff

You're welcome.

There's nothing that should cause Windows application issues--at least for a completed font. I've done several border fonts exported as OTFs that haven't had issues in Windows or Mac applications.

fwiw, I was using Affinity Designer, Windows ver., but also quickly tried QXP and ID. But as I mentioned, just as in the ZIP it simply wouldn't show in menus.

James Puckett

I’ve had trouble with broken OTF fonts in Wordpad in the past. But it was problem with Vietnamese characters.

Aaron Bell

Are you running into this issue with your fonts in general, or these specialized border fonts? I seem to recall something about Windows expecting a certain base character set to be present but why a TTF would work and an OTF wouldn't, I'm not sure. 

Oliver Weiss (Walden Font Co.)

@Aaron Bell Thank you, that might explain the issue, as the border fonts that do work have most if not the Latin-1 glyphs populated. I think what threw me off is that some applications are happy with this "short" font, while others aren't. It's a drag, as one of the main uses of the font will be via an application's glyph browser. I don't want to clutter that up with a bunch of empty characters. 
 

Thomas Phinney

Aaron’s right. I think it may be just one. But darned if I can remember what the specific character is.

Erwin Denissen

The font indeed fails to show characters in Windows Character Map, but when I just open and export it with FontCreator, they do show up. However it then also shows Latin characters from a fallback font. I guess this is just how the app works with fonts containing CFF based outlines.

Aaron Bell

Like @Thomas Phinney says, I think that some applications rely on a specific glyph to determine certain aspects of the font. Might be a GDI vs DWrite thing. And could be that in the TTF version, that required info is available elsewhere in the font data so this “magic glyph” is not necessary. 🤷‍♂️

My brain is suggesting to add the “H”… but I think you might need to do some testing.

John Hudson

First confirm that the OS/2 codepage bits are set to include at least one complete Windows 8-bit codepage such as CP 1252. If the font doesn’t actually support that codepage, lying about it in the OS/2 bit settings may still resolve the issue. If it doesn’t, that suggests a cmap check may be being performed, to identify some character or characters as being present. If you don’t want to clutter up your glyph set with a lot of empty cells, you can map all of the missing characters to cover the 8-bit set to a single glyph.

Oliver Weiss (Walden Font Co.)

Thank you all! I will give your suggestions a tomorrow. What I learned so far is that I don't know nearly enough about font engineering!