freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [ft] Creating an [OT]TF font from BDF font


From: George Williams
Subject: RE: [ft] Creating an [OT]TF font from BDF font
Date: 09 Dec 2005 14:46:33 -0800

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]