Font shows red in preview even though all characters available

Post your bug reports here. Include information that helps us to understand and reproduce the bug.
nabsltd
Posts: 47
Joined: Tue Oct 18, 2016 12:35 am

Font shows red in preview even though all characters available

Postby nabsltd » Fri Oct 21, 2016 5:06 pm

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).
PreviewSpace.jpg
PreviewSpace.jpg (26.42 KiB) Viewed 307 times

With the space gone from the preview, no red:
PreviewNoSpace.jpg
PreviewNoSpace.jpg (39 KiB) Viewed 307 times

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:
SpaceGlyphDetails.jpg
SpaceGlyphDetails.jpg (177.9 KiB) Viewed 307 times

Erwin Denissen
Moderator
Moderator
Posts: 6348
Joined: Fri Oct 04, 2002 12:41 am
Location: De Bilt, The Netherlands
Contact:

Re: Font shows red in preview even though all characters available

Postby Erwin Denissen » Fri Oct 21, 2016 5:31 pm

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?
Erwin Denissen
High-Logic
Proven Font Technology

nabsltd
Posts: 47
Joined: Tue Oct 18, 2016 12:35 am

Re: Font shows red in preview even though all characters available

Postby nabsltd » Fri Oct 21, 2016 6:27 pm

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?

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.

Bhikkhu Pesala
Top Typographer
Top Typographer
Posts: 6550
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

Postby Bhikkhu Pesala » Fri Oct 21, 2016 7:41 pm

My FontsReviews: MainTypeFont CreatorHelpFC10.1 Pro + MT7.0 @ Win10 1703

nabsltd
Posts: 47
Joined: Tue Oct 18, 2016 12:35 am

Re: Font shows red in preview even though all characters available

Postby nabsltd » Tue Oct 25, 2016 1:07 am

Bhikkhu Pesala wrote:Recommended Glyphs

So, it's not required to have those glyphs the OpenType spec, which means MainType should handle the font correctly.

Erwin Denissen
Moderator
Moderator
Posts: 6348
Joined: Fri Oct 04, 2002 12:41 am
Location: De Bilt, The Netherlands
Contact:

Re: Font shows red in preview even though all characters available

Postby Erwin Denissen » Tue Oct 25, 2016 12:59 pm

nabsltd wrote:Adding a ".notdef" glyph fixed the problem, so that was it.

That is good to know!

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.

MainType uses a default Windows control which has no options to change the way the rendering functionality works.
Erwin Denissen
High-Logic
Proven Font Technology

nabsltd
Posts: 47
Joined: Tue Oct 18, 2016 12:35 am

Re: Font shows red in preview even though all characters available

Postby nabsltd » Tue Oct 25, 2016 6:44 pm

Erwin Denissen wrote: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.

Erwin Denissen
Moderator
Moderator
Posts: 6348
Joined: Fri Oct 04, 2002 12:41 am
Location: De Bilt, The Netherlands
Contact:

Re: Font shows red in preview even though all characters available

Postby Erwin Denissen » Tue Oct 25, 2016 6:51 pm

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.
Erwin Denissen
High-Logic
Proven Font Technology


Return to “MainType - Bug Reports”

Who is online

Users browsing this forum: No registered users and 2 guests