© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
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.