http://bugs.winehq.org/show_bug.cgi?id=10660
--- Comment #25 from George Williams gww@silcom.com 2008-02-08 17:08:32 --- I have explained this three times on the fontforge mailing list. "I have answered three questions, and that is enough," Said his father. "Don't give yourself airs! Do you think I can listen all day to such stuff? Be off, or I'll kick you down stairs.
The problem is that marlett.sfd was taking advantage of a bug in fontforge. That bug has now been fixed. marlett.sfd is rather problematic itself as it claims an adobe symbol encoding when it does not, in fact, have one. I hope someone hand-edited the sfd file, because if not there is another bug in fontforge.
At one point I assumed that MicroSoft's 3,0 cmap entry was the same as Adobe's symbol encoding (To fontforge a "symbol" encoding is Adobe's). It is not. In fact MicroSoft's 3,0 cmap entry is not a true encoding as there is no charset associated with it. At any rate FontForge no longer generates a 3,0 cmap entry for something with Adobe's Symbol encoding.
As Stephan says I am extremely tired of repeating this same point over and over. A dieu.