Repairing glyphs

[Leon Gauthier]

When the validation wizard gives me a list of glyphs which it cannot repair, I save the text file when there are many and I search for them, one after the other, to repair them. Several times now, when I double-click on the “found” glyph in order to edit it and the real-time glyph validation window gives me another glyph index, #421, and says “No problems detected”.

459.JPG (290.93 KiB) Viewed 4374 times

After confirming that the pointing finger is @ #459, I search again
[rejected]
and when I open it again, I get yet another index #, #539.
[rejected]
It would not surprise me that there is a flaw in this font file but what could it be? After saving the file and reopening, I scrolled the overview to #459 as shown here:
[rejected]
When I double-click #456, the real-time validation identifies it as #455 and continues to identify each successive glyph as #455 as I click “next glyph” right until I reach $460 where it identifies it as #460.

[Bhikkhu Pesala]

I think we weill need the font file. I cannot reproduce it with my own fonts.

I wonder if you have some empty glyphs at the start of the font that upsetting the glyph index, or something like that. You could try Sorting the font from the Tools menu and see if that fixes the issue.

[Erwin Denissen]

The glyph validator currently won't check the glyph as it is too complex. You can increase validation limits through the options dialog.

[Leon Gauthier]

Glyph #0 is empty .notdef. I remember seeing a list of the minimum required glyphs some where on this board but I'll be darned if I can find it. I thought .notdef was ordinarily displayed when a codepoint could not be found in the font and usually had a little rectangle to represent an empty glyph. #1 is also empty, .null with codepoints $00, $08, $1D.

I sorted by unicodepoints and the pointing fingers have new glyph #'s. However, when I step thru them, the glyph # in real time validation ignores them other than to say “glyph too complex”. The font validation wizard now only finds fault with #298 which is the second in the sequence of four. All four are too complex to even count I guess.

[Leon Gauthier]

I can imagine that these are full of errors.

[Leon Gauthier]

Hah, when I reopened the first glyph to estimate the number of contours, the real-time validation identified it as #492 while it is really #297. There were not too many contours so I just upped the point limit to 600 and "No problems detected". #298 had one little problem an #299 and #300 were just fine. I'll return the point limit to 400 just to be alerted about "complex" glyphs.

The more I use this software, the more impressed I am ... in these fonts FC has fixed hundred's of problems and made fixing those it couldn't very easy.
Thanks, guys.

So then the empty #0 .notdef is ok? It just needs a little rectangle?

[Leon Gauthier]

FYI: It appears that the # displayed by the real-time validation routine when one opens a "too complex" glyph is the last # displayed by the real-time validation.

[Bhikkhu Pesala]

So then the empty #0 .notdef is ok? It just needs a little rectangle?

It is recommended to use a glyph in the .notdef glyph — otherwise no one will know if the glyph is not defined or is just a space glyph.

MS Recommendations for Type Design Standards

I always use the middle one as I think it has the most obvious meaning. The other two designs could easily be confused with actual glyphs.

not defined glyphs.png (2.47 KiB) Viewed 4365 times