This content has been marked as final. Show 8 replies
There was a space in the link. The correct URL is:
I'd like to hear Adobe weigh in on this as well.
I can't say for sure what is causing the problem, but I suspect it's bad outlines. For example, the inside counter of the "D" at the lower left has three consecutive points on the path that are all at the same coordinates.
Broadly speaking, the outlines look like they were converted from TrueType in some automated way that left a moderate number of extraneous points which should be deleted and cleaned up.
Additionally, I'll note that the outlines sure look like they're somebody's version of Helvetica. I'll just note that converting a font from another format, if that's what happened, does not eliminate the copyright of the original, nor make it okay to drop the copyright and trademark notices.
The problem, I think, is that this was a originally a truetype font and you convert it to postscript (bezier) font, but you did not change the scale to 1000 and keep it at 2048.
Actually, although it can cause some very minor issues, having a 2048 em square is perfectly legal in Type 1 and OpenType CFF. Unusual, but legal. However, one could try changing the em value just to see if it helps.
Another issue in this font is that is incorrectly flagged as monospaced. That shouldn't crash a rasterizer, however - just lead to messed up spacing in some environments.
Re - Thomas Phinney's comment that converting a font doesn't change
the copyright info etc.
I've found a number of poorly made, home-brewed fonts that have a ©
notice from a major foundry - often Adobe.
I'm sure that what happens is that people have taken an Adobe font to
use as a template, deleted all the glyphs and created their own,
without ever bothering to change the © notice. Occasionally they've
used a program that doesn't change all the font names either, and it
ends up with a font named "MYSTUFF" in all but, for example, the
PSName, where it's "Helvetica".
The FDK tools actually have a lot to say about this font. 'checkOutlines' reports many serious problems - wrong path direction, intersections, overlaps, coincident points and paths, and more!. However, the 'tx' tool can resterize this font (see 'tx -bc -h' for help on using tx to show glyphs). Since the tx tool contains the main Adobe rasterizer, the outline errors are not likely to be the source of the problem. The 'comapreFamily" tool reports many significant problems. Two are fatal problems, and alone could account for the font not loading under Windows XP. One is that the PostScript name reported in the 'name' table is not the same as the real PostScript name in the CFF font table. the other is that head table fontRevision is 1.0. CFF rasterizers from early in the OpenType era will often reject OpenType CFF fonts with a version of 1.0 or less. I forget whether Widows XP still does this, but it is worth checking as a possible fatal error. The most significant non-fatal error is that the head table reports the em-square as being 2048, and the design suggests that this is correct, but the CFF Font matrix is he default, which is 1000. This will cause the glyphs to rasterize at about double the intended point size. Finally, not all apps and OS's are fully supportive of CID-keyed CFF tables designed for a non-CJK system, such as this font. Some environments just assume that such are CJK fonts, and won't load them if they are missing a vmtx table and some glyphs in a CJK Unicode block. However, this wouldn't be a problem with just Windows XP and Wordpad.
I am pretty sure that rejection thing is only if the value is LESS than 1.0, not equal to 1.0 or less. But I expect all the rest of Read's analysis is correct....