Thank you for the explanation. We will look into it and will keep you informed of any action from our part. Meanwhile, have a great week.
Sincerely yours, Nguyen Trung Chi NEC Solutions VietNam -----Original Message----- From: Werner LEMBERG [mailto:[email protected]] Sent: Sunday, January 11, 2009 6:30 PM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB standard > 1) The freetype2 API reference implies that if a given face is from > a BDF or PCF font and if the 'prop_name' is "RESOLUTION_X", the > function FT_Get_BDF_Property() will return 'aproperty' with its type > is 'BDF_PROPERTY_TYPE_CARDINAL' and its 'u.cardinal' has correct > value. > > So when FT_Get_BDF_Property() is called with 'prop_name' is > "RESOLUTION_X" and a given face from PCF font, the function should > return 'aproperty' with its type equal to > 'BDF_PROPERTY_TYPE_CARDINAL'. > > However, the function returns 'BDF_PROPERTY_TYPE_INTEGER' instead. This is correct behaviour but not documented. First of all, there is no specification for the PCF format; you have to read it from the X11 sources directly. However, George Williams extracted the data to document the format: http://fontforge.sourceforge.net/pcf-format.html There you can see that PCF properties are stored like this: struct props { int32 name_offset; /* Offset into the following string table */ int8 isStringProp; int32 value; /* The value for integer props, the offset for string props */ } props[nprops]; In other words, PCF doesn't make a distinction between signed and unsigned integers; the value is always stored (and read using the `atoi' function) as signed. > 2) The freetype2 API reference also implies that if the given face > is from a BDF or PCF font and if the 'prop_name' is "FONT", then > if this "FONT" field exists in the given face, the function > FT_Get_BDF_Property() will return 'aproperty' with its type equal > to 'BDF_PROPERTY_TYPE_ATOM' and its 'u.atom' has the correct > value as read from the font file using the FontForge utility. This is not correct in this particular case. `FONT' is not a BDF property in this font! It's not within the STARTPROPERTIES ... ENDPROPERTIES block and can thus not be extracted with FT_Get_BDF_Property (the function returns an error). However, it might be useful to handle all global key-value pairs within a BDF as if they were `properties'. If you think that such a feature is useful please file a bug report at https://savannah.nongnu.org/bugs/?group=freetype so that this request won't get lost. I'll document both items. Werner _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
