After reading carefully the replies, the current front-runner isWhen PfaEdit generates a (non-mac) bitmap only sfnt it currently uses the .ttf extension. This has the advantage that programs (such as windows) that don't know about new extensions will work on these fonts. Is there a real need to distinguish between bitmap only and ouline sfnts? (I presume this question was answered earlier in the discussion but I wasn't involved)
``otb'', for ``OpenType Bitmap''. Is that extension used up yet? DD> With the proviso that there has been some research to determine
DD> that nobody else is already using an extension for fonts like
(And even though Windows doesn't use bitmap only fonts it is possible to trick it into accepted them by adding a dummy glyph table with a lot of spaces, and an embedded bitmap scaling table that maps all (likely) pixel sizes to one of the bitmap strikes)
I presume that an .otb font would just have EBDT/EBLC and I should not generate a dummy glyf/loca/EBSC?
I presume also that it should have a head table and not a bhed, and EBDT/EBLC rather than bdat/bloc?
(It's no more bizzare than the old resource format, the two are almost exactly the same except dfonts live in the data fork rather than the resource fork -- I'd say that makes it a little less bizarre:)They also have a bizarre encoding of SFNTs on Mac OS X. The extension is ``.dfont'', and is not specific to bitmap-only fonts.
But you are right, dfont would be an inappropriate extension.
(Both freetype and pfaedit should now be able to handle the dfont format even on non mac systems)
If anyone knows of a system that does use file extensions and that does use bitmap-only SFNTs, I'm quite willing to be compatible.
I know of none. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
