This content has been marked as final. Show 4 replies
spot and CompareFamily are not able to process CFF or Type 1 font files, CID-keyed or otherwise. These work only with OpenType fonts. They do, however, work with OpenType CFF files that have CFF tables, both name-keyed and CID-keyed.
If spot is reporting a problem with an OpenType font with a CFF table, there is probaby a real problem. If this is the case, could you send me the report from spot?
- Read Roberts
The error I get from the 'spot' is as follows:
C:\>spot -t CFF out.otf
spot [FATAL]: CFF parsing
Python error while running command
A test file in question is:
and the embedded CFF file is
As I mentioned in my last email, CFFChecker from FDK16 does not report any problems in the embedded CFF font and all data is properly extracted.
Since the error report from 'spot' is not very informative, could you please tell me at what point does the assertion/error occurs.
Hi Ivan;<br /><br />Thank you for the test font, this was very helpful.<br /><br />There are two errors in this CFF table, both of which are major.<br /><br /> One is that the length of the PrivateDict entry is 0, and of course then has no entries. Although the CFF specification is silent on required tables and entries, there is no default for the BlueValue entry in the Private Dict, and the Type 1 spec notes that this entry is required, although it may be en empty array. This was what caused the spot tool to fail. I would expect failures in other tools and rasterizers as well, since what should happen in the case of missing required CFF PrivateDict entries is not specified anywhere.<br /><br />Another problem is in the charset table in the CFF. This causes the ttx tool to fail (the font <-> XML text decompiler/compiler). The numLeft field is one too high. This causes an interpreter to ask for a CFF name string ID ( SID) one greater than used for any glyph, and assign it to a glyph whose GID is one higher than the last glyph in the font. Since there are very few glyphs in the font, the requested SID is in the hard-coded range, but for a large CID font, this could lead to an attempt to index an SID higher than any which exist, and a crash. Even when this happens to not cause an immediate problem, assigning the SID to a glyph reference that doesnt exist is also likely to cause problems.<br /><br />The reason this charset table is in error is as follows.<br />There is an obscurely placed comment in the CFF spec under the description of charset format 0 which says 'The number of glyphs (nGlyphs) is the value of the count field in the CharStrings INDEX. (There is one less element in the glyph name array than nGlyphs because the .notdef glyph name is omitted.)". This note applies to all the charset formats. By the definition of the spec, glyph ID 0 is .notdef. This is a hard assumption, and the glyph is therefore omitted from the charset range coverage. Your font has 16 glyphs. The charset definition is format 2, and has only one range, which thus covers glyph ID's 1-15. However, the charset range data is "SID=1,numLeft=15". This says that the first glyph ( GID = 1) in the range gets the name string ID 1, and then there are 15 more with sequential name string ID's. Since the first glyph covered by this range is GID 1, the last one will be GID 16 ( the seventeenth glyph), and there isn't a seventeenth glyph..<br /><br />You can see the details of the CFF structure of a font with the command 'tx -dcf <font path>. See tx dcf h for the various options which limit the dump to one or more CFF sub-tables.<br /><br />I notice that although the CFF data and head table both specify an em-square of 1000 for this font, the 'tx' tool is reporting in its summary report ('tx -dump <font-file> an obviously incorrect em-square of 16960 and a font Matrix a and b values of 1.0e-6, and the Adobe core rasterizer library won't show a glyph. I suspect that these are side-effects of the two problems above.<br /><br />Hope this helps,<br /><br /> - Read Roberts
P.S. From your use of CFFChecker, which was the FDK.16 equivalent of 'tx', I think you are still using the FDK.1.6. The 'tx' and 'ttx' tools are command-line tools included in ther FDK2.0. In the FDK 2.0, the Python GUI wrappers for the underlying libraries were abandoned and replaced with command-line tools.