[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: |
Chi Nguyen |
Subject: |
RE: [ft-devel] FT_Get_BDF_Property() function does not satisfy LSB standard |
Date: |
Mon, 12 Jan 2009 09:53:38 +0700 |
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:address@hidden
Sent: Sunday, January 11, 2009 6:30 PM
To: address@hidden
Cc: address@hidden; address@hidden;
address@hidden; address@hidden
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