Microsoft Font Validator adds CFF checking

Hin-Tak Leung

2016-02-08 was tagged on github ( https://github.com/HinTak/Font-Validator ).

Code snapshots (-src-*), mono/.net binaries (*-bin-*) and Mac OS X disk images (*.dmg) are at:

http://sourceforge.net/projects/hp-pxl-jetready/files/Microsoft Font Validator/

Compared to last (SVG addition on 2016-01-22), the main addition is the long-overdue addition of CFF checking. This flags errors in quite a few fonts from well-known vendors: Adobe's Arno fonts, Mozilla's Fira fonts and two font sets from the TeXLive distribution for having non-ascii strings in the String INDEX , and two fonts from Apple's OS X for using obsolete dictionary keys (removed 16 years ago). And possibly many more. Please contact the relevant font vendors if/when you see CFF errors flagged.

The issues with these fonts and CFF were discussed on the Opentype mailing list.

So it looks like this work is much needed - and there are a few more CFF checks to add; I 'll put an github issue entry up for further work.

There is a small GDEF update to check additional fields introduced in v1002, and workaround to two mono bugs to show correct build version under "about..." in the GUI.

Please do make a donation (
http://sourceforge.net/p/hp-pxl-jetready/donate/) if you find this useful. I am still exploring how this might continue.

Interested parties, from the large corporations like Microsoft, Adobe, Google, Apple, to smaller schools and universities teaching typography/font design, foundaries, please consider commissioning part of the continual development.

Oh, and Happy Chinese New Year!!!!

James Puckett

Is there any reason to assume that the CFF errors actually cause problems with popular OTL/rendering engines or software? Or are these errors just things that are out of spec but don’t cause trouble?

Also, I can’t look up the new errors in help because the help viewer is broken. I can select errors, but the description Window is blank.

Hin-Tak Leung

It is difficult to tell - in the String INDEX case, the issues I found are of people putting copyright signs in either utf8 or Latin1 encoding, or the author's own non-English name in the copyright/notice field. These are not used by most font engines since the equivalent fields in the name table are obviously preferred. But the String INDEX is more commonly used for glyph names, and non-ascii glyph name is a big no-no, I think. So it depends on whether you want to distinguish the two usages of the String INDEX for benign dictionary fields vs glyph names.

In the obsolete dictionary key case, the error is currently captured in the generic "failed to parse dictionary" case - which is on the whole very serious. I suppose if you insist, I can insert a 'parse this obsolete code anyway and give a warning" and make a special case for it; but then I have only seen it on two fonts (out of about 1600) - and it just happens to be shipped by Apple and they have not updated the fonts for 16 years.

So those are generic errors which "could" be serious, but not in the cases I saw.

Hin-Tak Leung

The chm works okay here - the info there is just a shorter version of the first paragraph above.