Hi George, 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 USHORT stringTable : offset (from start of table) to string table note that the string table ends at the end of the BDF table. Each string is 8-bit and 0-terminated. 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 (e.g. COMMENT, FONTBOUNDINGBOX, etc..) 1 => string property 2 => int32 property 3 => uint32 property ULONG item_value : item value. non-prop => an offset into the string table that contain the original text that followed the item in the original BDF font strings => an offset into the string table to the corresponding string, without the surrending double-quotes integers => the corresponding 32-bit value note also that: - the string table is always stored after all value sets, i.e. stringTable = 6 + 4*strikeCount + 6*sum(n in [0..strikeCount-1], num_items[n]) - here's some (unsafe) code to parse the table in order to find properties: extern FT_Error find_bdf_property( FT_Byte* bdf_table, int strike_ppem, const char* prop_name, BDF_PropertyRec *aprop ) { FT_Byte* p = bdf_table + 2; FT_UInt num_strikes = TT_NEXT_USHORT(p); FT_Byte* strings = bdf_table + TT_NEXT_USHORT(p); FT_Byte* strike = p + 4*num_strikes; FT_UInt num_items = 0; /* first of all, find the strike */ for ( ; num_strikes > 0; num_strikes-- ) { FT_UInt ppem; ppem = TT_NEXT_USHORT(p); item_count = TT_NEXT_USHORT(p) & 0xFF; if ( ppem == strike_ppem ) goto FoundStrike; strike += item_count*8; } goto NotFound; FoundStrike: p = strike; for ( ; item_count > 0; item_count--, p += 8 ) { FT_UInt kind = TT_PEEK_USHORT(p+2); if ( kind >= 2 && kind <= 4 ) { FT_Byte* name = strings + TT_PEEK_USHORT(p); if ( ft_strcmp( name, prop_name ) == 0 ) { FT_UInt32 value = TT_PEEK_ULONG(p+4); switch ( kind ) { case 1: /* string */ aprop->type = BDF_PROPERTY_TYPE_ATOM; aprop->u.atom = (const char*)(strings + value); break; case 2: /* int32 */ aprop->type = BDF_PROPERTY_TYPE_INTEGER; aprop->u.integer = (FT_Int32)value; break; default: aprop->type = BDF_PROPERTY_TYPE_CARDINAL; aprop->u.integer = value; } return 0; } } } NotFound: aprop->type = BDF_PROPERTY_TYPE_NONE; return FT_Err_Invalid_Argument; } What do you think about it ? - David Turner - The FreeType Project (www.freetype.org) > -----Message d'origine----- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la > part de George > Williams > Envoyé : vendredi 9 décembre 2005 02:47 > À : Keith Packard > Cc : freetype@nongnu.org; fonts@xfree86.org > Objet : Re: [ft] Creating an [OT]TF font from BDF font > > > On Thu, 2005-12-08 at 16:46, Keith Packard wrote: > > Yes, this was my plan. I got side-tracked before I managed > to implement > > it though. > > > > I need this + a utility to regenerate BDF files from the > TTF so I can > > validate a lossless round-trip for the existing BDF files. > > > > If anyone wants to pick up this little project, I can > assure them that > Well I'll certainly make fontforge support a BDF table for > otb fonts (ff > can already go bdf->otb->bdf, but it loses the properties -- and then > regenerates the standard ones). > > So I presume the BDF table would contain an entry for each strike, and > contain any of the junk between STARTFONT and CHARS? > > I propose the following format for the BDF table: > <uint16> 1 #version > <uint16> n #number of strikes > <uint16> offset to start of string/atom table > > n instances of the following structure > <uint16> #ppem > <uint16> #offset (from start of BDF table) to information on this > strike > > Strike info would look like: > <uint16> ni #count of non-property information > FONT, SIZE, FONTBOUNDINGBOX, COMMENT, etc. > <uint16> np #count of property > > ni instances of the following structure > <uint16> #offset from start of string table to atom name > <uint16> #type of data: 0 => atom, 1 => string, 2 => integer > <u/int16> #offset into string table for atom/string, or the value for > integers > > np instances of the same structure for the properties. > > The string table would be a set of NUL terminated ASCII strings. > > (BDF fonts are said to be ASCII. I have seen many containing latin1 > characters especially the copyright mark ©. I wonder if these > should be > converted to UTF-8? or UCS-2?) > > > > _______________________________________________ > Freetype mailing list > Freetype@nongnu.org > http://lists.nongnu.org/mailman/listinfo/freetype > *********************************************************************************** Information contained in this email message is confidential and may be privileged, and is intended only for use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the [EMAIL PROTECTED] and destroy the original message. ***********************************************************************************
_______________________________________________ Freetype mailing list Freetype@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype