I have a lot of fonts that show as red in the preview (implying missing characters from the preview), even though all characters are there.
Many of these fonts have been run through FontCreator by me to change properties like name, foundry, embedding, etc., but some have been untouched. It turns out that the “missing” character in all these fonts is the space (ASCII 0x20).
With the space gone from the preview, no red:
I’ve looked at the fonts, and it appears that if the glyph for space is mapped to more code points than $20, that triggers the problem:
I think the main issue is the fact the first glyph is known as the missing glyph. So if you have your space character mapped to the first glyph, it is treated as missing. Can you confirm this?
Adding a “.notdef” glyph fixed the problem, so that was it.
Is having the first/missing glpyh also mapped to a code point a violation of the OpenType spec? If not, then MainType should handle this correctly and not show the preview in red.
Also, is it possible that FontCreator does something that can create this issue with commercial fonts that don’t already have it? Generally, all I do is sort by Unicode codepoint, and then change some of the properties (like name). My original “AdobeGaramondPro-regular.otf” file doesn’t show this issue, but the version with the font renamed to “Adobe Garamond Pro” using FontCreator 8.0 does. I just ran it through FontCreator 10 and sorted the glyphs, then renamed, and there were no issues, so maybe it’s an old bug. Either way, an enhancement to FontCreator’s Validation that makes sure that the first glyph is an unmapped “.notdef” glyph would be nice.
So, it’s not required to have those glyphs the OpenType spec, which means MainType should handle the font correctly.
That is good to know!
MainType uses a default Windows control which has no options to change the way the rendering functionality works.
You must do something, because you decide to change to red text if characters are missing. The control doesn’t know about such things…only MainType does. So, change your “missing” logic so that fonts without truly missing characters don’t display in red.
Point taken. We use a windows API to detect if all characters are available. I doubt if we can do anything easy to improve this. Of course we can build our own logic, but we have more important things on our to-do list.