JC> The resultant ttfs should also, IMO, include sufficient hints so that
JC> mkfontdir can generate fonts.dir entries from them exactly as it now
JC> can from the bdf files. In fact, all of the properties from the bdf
JC> files' STARTPROPERTIES section should be encoded into the ttf.
Do we or don't we want to support non-standard font properties?
JC> Or perhaps the current tables are sufficient to encode all of that
JC> data.
No, they aren't. There's no way to encode a foundry name that hasn't
been standardised by Microsoft. There's also no way to encode the
XLFD charset of a symbol font.
Let alone non-standard properties, such as the various _DEC_* thingies
that are present in some of the SI's fonts.
KP> If anyone has experience writing TrueType font files, help
KP> would be greatly appreciated in building something that can
KP> create these new files.
I looked at what can be done when we first discussed the idea.
Fonts in that format cannot be compressed -- OTF is intrinsically a
seekable format. On the other hand, sbits are a highly compact
format, allowing among others sharing glyphs (even between different
strokes) and bit-aligned rasters (Mac-style; Microsoft-style are
byte-aligned).
Additionally, it is possible to have a very compact format for
composites (similar to the Type 1 seac operator); if anyone knows of a
good algorithm for detecting such optimisations, I'm curious to hear
you.
I'm planning to modify mkfontscale to generate scalable entries only
if outlines are present, and to generate non-scalable entries
otherwise by checking what sbit strokes are included.
JC> Alternatively, pfaedit ought to be able to do this right now, and
JC> could be scripted to automate the task.
AFAIK, pfaedit will only output sbits for glyphs that also have an
outline.
Juliusz
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
