FDK errors while validating the font

[_Ivan_Nincic_]

Hello, <br /><br />I am using FDF toolkit to test some CFF and OpenType(CFF) fonts, but I am getting mixed messages. <br /><br />The CFF font (http://www.pdftron.com/pub/cfftest.zip) is actually a CID font and is using a single range (0, 0xFFFF) in the Charset dictionary of CFF font. <br /><br />When I run or CFFChecker (using the older FDK) I get lots of information (see below). Also FDK tools can successfully embed/render the CFF font in PDF. However, spot and some other tools report errors when I try to dump the CFF table saying that there is an error in CFF data.<br /><br />So are 'spot' and other FDK tools able to handle this type of CFF fonts (i.e. the fonts that use CID map as described above)? Is there anything wrong with this font? Are there any other resources that can help us to validate Adobe CFF format?<br /><br />Thank You, <br /><br />IvanN<br /><br />-------------<br />C:\>python CFFChecker.py<br /><br />Imported txlib v.1.5.4750<br />-dcf -y <br />### Header (00000000-00000003)<br />major =1<br />minor =0<br />hdrSize=4<br />offSize=4<br />### Name INDEX (00000004-00000014)<br />--- object[index]={value}<br />[0]={IK_FNT}<br />### Top DICT INDEX (00000015-00000055)<br />--- object[index]={value}<br />[0]={<br />393 394 0 ROS<br />391 FullName<br />392 FamilyName<br />0 0 1000 1000 FontBBox<br />0.001 0 0 0.001 0 0 FontMatrix<br />1 StrokeWidth<br />142 charset<br />155 CharStrings<br />17 CIDCount<br />1108 FDArray<br />147 FDIndex<br />}<br />### String INDEX (00000056-0000008b)<br />--- object[index]={value}<br />[391]={IK_FNT}<br />[392]={IK_FNTFamily}<br />[393]={Adobe}<br />[394]={Identity}<br />### GlobalSubrINDEX (0000008c-0000008d)<br />empty<br />### Charset (0000008e-00000092)<br />format=2<br />--- Range2[index]={first,nLeft}<br />[0]={1,16}<br />### FDSelect (00000093-0000009a)<br />format =3<br />nRanges=1<br />--- Range3[index]={first,fd}<br />[0]={0,0}<br />sentinel=17<br />### FDArray INDEX (00000454-00000483)<br />--- object[index]={value}<br />[0]={<br />391 FullName<br />392 FamilyName<br />0 0 1000 1000 FontBBox<br />0.001 0 0 0.001 0 0 FontMatrix<br />1 StrokeWidth<br />391 FontName<br />0 0 Private<br />}<br />### CharStrings INDEX (0000009b-00000453)<br />--- object[index]={value}<br />[0]={<br />100 10 12 rmoveto<br />120 133 rlineto<br />endchar<br />}<br />[1]={<br />150 10 12 rmoveto<br />120 133 rlineto<br />endchar<br />} <br />... <snip> ...<br />}<br />### Private DICT (00000000-ffffffff)

[_Read_Roberts_]

Hi Ivan;

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

[_Ivan_Nincic_]

Hello Read,

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
AssertionError
-----------------------------------

A test file in question is:
http://www.pdftron.com/pub/test.otf

and the embedded CFF file is
http://www.pdftron.com/pub/test.cff

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.

Thank You,

Ivan

[_Read_Roberts_]

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

[_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.

- Read