From: George W. <gw...@si...> - 2005-07-19 04:39:55
|
On Mon, 2005-07-18 at 16:42, Peter Dyballa wrote: > I changed some statements in the script file, closing and opening font > files, so I could create the PFB and AFM files. The AFM file for the 8p > encoded font misses many code points. This would be OK because they're > not contained in the TTF file, but what's incorrect is that FontForge > does not write .notdef in that case but starts to increment the C > number when it finds again a glyph in the TTF file. So the AFM file > does not follow the given encoding -- and the PS font file too! This > looks to me like a bug ... Um. The AFM file does not have an entry for .notdef because AFM files don't. The pfb encoding vector first sets everything to .notdef and then sets the non-notdef entries. As far as I can tell the encoding in the PFB file is correct -- It has ASCII where it should and TeX stuff elsewhere. As far as I can tell the encoding in the AFM file is also correct. C 32 ; WX 390 ; WY 1000 ; N uni0020 ; B 0 0 0 0 ; says that unicode 0020 (space) should be encoded at slot 32. |