I realized last night that my proposal was incomplete. I like David's suggestion of getting rid of my separate lists (for prop/non-prop) and including that in the type field -- however non-properties can have non-string values and both properties and non-properties can have arrays of integers as values.
There is a distinction between keywords that take atoms as values (FONT) and those which take strings as values (most everything else). I think that should be maintained. David suggests storing 32 bit values. I don't see that is needed in a BDF file... unless we get fonts with ppem around 64k. But perhaps it would be needed for offsets if there are a lot of strikes. So I'd suggest changing the offset to the string table to be 32bit too. So I'd like to make the following changes to David's proposal: On Fri, 2005-12-09 at 02:02, Turner, David wrote: > I think it's a nice proposal, but I'd like to provide an alternative. > The idea being that to avoid two subtables indirections, as well as > the separation of properties/non-properties you made, since I believe > it might be important to re-create a BDF font file with atoms listed > in the correct order: > > ----------------------------------cut here------------------------------- > the format of the 'BDF' SFNT table is the following: > > > USHORT version : 'BDF' table version number, must be 0x0001 > USHORT strikeCount : number of strikes in table ULONG stringTable : offset (from start of table) to string table > Each string is 8-bit and > 0-terminated. the end of the string sub-table will be the start of the array sub-table. ULONG arrayTable : offset (from start of table) to array sub-table Each array of type LONG and is preceded by an element count. the sub-table will end will be the end of the BDF table itself. > > followed by an array of 'strikeCount' descriptors that look like: > > USHORT ppem : vertical pixels-per-EM for this strike > USHORT num_items : number of items (properties and atoms), max is 255 > > this array is followed by 'strikeCount' value sets. Each "value set" is > an array of (num_items) items that look like: > > USHORT item_name : offset in string table to item name > USHORT item_type : item type: 0 => non-property string (e.g. COMMENT) 1 => non-property atom (e.g. FONT) 2 => non-property int32 3 => non-property uint32 4 => non-property array of int32 (e.g. SIZE, FONTBOUNDINGBOX, DWIDTH) 0x10 => flag for a property, ored with above value types) > > ULONG item_value : item value. > strings => an offset into the string table > to the corresponding string, > without the surrending double-quotes atoms => an offset into the string table > > integers => the corresponding 32-bit value arrays => an offset into the array table an array starts with an element count and is followed by that many signed int32s. So SIZE 8 75 75 would be stored as 3 8 75 75 _______________________________________________ Fonts mailing list Fonts@XFree86.Org http://XFree86.Org/mailman/listinfo/fonts