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:
Font shows red in preview even though all characters available [Closed]
-
- Moderator
- Posts: 11227
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Font shows red in preview even though all characters available
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?
Re: Font shows red in preview even though all characters available
Adding a ".notdef" glyph fixed the problem, so that was it.Erwin Denissen wrote: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?
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.
-
- Top Typographer
- Posts: 9890
- Joined: Tue Oct 29, 2002 5:28 am
- Location: Seven Kings, London UK
- Contact:
Re: Font shows red in preview even though all characters available
So, it's not required to have those glyphs the OpenType spec, which means MainType should handle the font correctly.Bhikkhu Pesala wrote:Recommended Glyphs
-
- Moderator
- Posts: 11227
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Font shows red in preview even though all characters available
That is good to know!nabsltd wrote:Adding a ".notdef" glyph fixed the problem, so that was it.
MainType uses a default Windows control which has no options to change the way the rendering functionality works.nabsltd wrote: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.
Re: Font shows red in preview even though all characters available
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.Erwin Denissen wrote:MainType uses a default Windows control which has no options to change the way the rendering functionality works.
-
- Moderator
- Posts: 11227
- Joined: Fri Oct 04, 2002 12:41 am
- Location: Bilthoven, The Netherlands
- Contact:
Re: Font shows red in preview even though all characters available
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.