[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB stand
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB standard |
Date: |
Sun, 11 Jan 2009 12:29:41 +0100 (CET) |
> 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